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Specification: 

ABSTRACT: 

Applicant is reminded of the proper language and format for an abstract of the disclosure. 

The abstract should be in narrative form and generally limited to a single paragraph on a 
separate sheet within the range of 50 to 1 50 words. It is important that the abstract not exceed 
150 words in length since the space provided for the abstract on the computer tape used by the 
printer is limited. The form and legal phraseology often used in patent claims, such as "means" 
and "said," should be avoided. The abstract should describe the disclosure sufficiently to assist 
readers in deciding whether there is a need for consulting the full patent text for details. 

The language should be clear and concise and should not repeat information given in the 
title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," 
"The disclosure defined by this invention," "The disclosure describes," etc. 

Claim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

Claims 1-5 are rejected under 35 U.S.C. 102(b) as being anticipated by US Pat No 
6,016,478 issued to Zhang et al (hereafter Zhang). 
Claim 1: 

Zhang discloses a coded system for use on a computer and including a journal software 
package, said coded system comprising: 
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• at least one module; a plurality of prompts in the form of questions and an entering 
device for enabling a user to answer said questions [Figs 5A-G and col 11, line 5 - col 12, 
line 10] 

• said plurality of prompts is directed to a specific category and will aid an individual to 
organize entered data [Figs 5A-G and col 11, line 5 - col 12, line 10] 

• said questions provide input of needs, relationship, demographically information, 
preferences, strengths and pertinent information of said individual and said questions are 
to be answered by said individual [Figs 5A-G and col 11, line 5 - col 12, line 10] 

• said at least one module is computer code and is coupled to an existing journal software 
package [Figs 5A-G and col 1 1, line 5 - col 12, line 10] 

• an entering device for entering answers from said questions into said computer and 
provides data for a data base and said data base is used by said computer code of said at 
least one module [Figs 5A-G and col 11, line 5 - col 12, line 10] 

• said at least one module interprets, processes and analyzes said data for organizing said 
data and links to said journal for enabling appropriate output [ 

Claim 2: 

Zhang discloses wherein at least two modules are provided and each module includes a 
separate set of prompts containing questions geared to a particular category, each module being a 
separate computer code and a user can select which module to active [Fig 5C]. 

Claim 3: 



Application/Control Number: 09/925,877 Page 4 

Art Unit: 2171 

Zhang discloses wherein a security system is included for enabling a user to correctly 
input in a code for accessing said coded system and said security system and said at least one 
module form a controlling station [Fig 5C] 

Claim 4: 

Zhang discloses wherein each of said at least one module includes prompts, which will 
enable advance-planning capability [col 11, lines 5-15] 

Claim 5: 

Zhang discloses wherein each of said at least one module includes the capability of 
calculating a specific date for alerting a user to do a specific task prior to a specific event [Fig 
5H]. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure: 

1) US Pat No. 6,369,840 issued to Bamett et al discloses generating and displaying a 
calendar containing user-selected events from user-selected categories, 

2) US Pat No. 6,466,236 issued to Pivowar et al discloses a portable handheld personal 
digital assistant for simultaneously displaying multiple calendars. 



Application/Control Number: 09/925,877 



Page 5 



Art Unit: 2171 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Etienne LeRoux whose telephone number is (703) 305-0620. 
The examiner can normally be reached on Monday - Friday from 8:00 AM to 4:30 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Safet Metjahic, can be reached on (703) 308-1436. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703) 305-3900. 

Patent related correspondence can be forwarded via the following FAX number (703) 
872-9306 
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[57] ABSTRACT 

An electronic Personal Information Manager (PIM) includ- 
ing a peer-to-peer group scheduling/calendar system is 
described. The group scheduling/calendar system provides 
methods for peer-to-peer group scheduling among users, 
including those users who only have simple e-mail support 
(i.e., do not have access to the group scheduling/calendar 
system itself). If a user is able to receive and respond to 
e-mail, he or she is able to participate in group scheduling 
in an automated fashion. Under user control, the system 
generates a scheduling invitation incorporating different 
formats. Each format includes, in order of increasing content 
richness, a simple text embedded scheduling invitation, an 
HTML (Hypertext Markup Language) form embedded 
scheduling invitation, and a proprietary binary "MIME" 
(Multipurpose Internet Mail Extensions) scheduling invita- 
tion. Each format is designed to transfer the highest degree 
of information content which a particular target client type 
can handle. A recipient of the scheduling message employs 
the messaging format best suited for his or her environment. 
Regardless of which format the recipient employs, the group 
scheduling system processes the reply message 
automatically, with the appropriate information automati- 
cally included in the user's group scheduling calendar. The 
system supports different levels of participation of various 
individuals throughout various stages of group scheduling, 
despite the fact that some of the individuals who need to 
participate might use other proprietary software and reside 
in other time zones. 

36 Claims, 36 Drawing Sheets 
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SCHEDULING SYSTEM WITH METHODS other users in an automated fashion, but without requiring 

FOR PEER-TO-PEER SCHEDULING OF the users of the group to employ or be connected to a 

REMOTE USERS particular proprietary system. In particular, such a system 

COPYRIGHT NOTICE should allow a user to initiate a message to invite a group of 

5 people to a meeting (i.e., to schedule a meeting). Those 

A portion of the disclosure of this patent document individuals should, if they are able to receive electronic 

contains material which is subject to copyright protection. mail, be able to participate in the group scheduling. Here, the 

The copyright owner has no objection to the facsimile recipients need not have access to any particular proprietary 

reproduction by anyone of the patent document or the patent software for participating in the group scheduling. Instead, 

disclosure as it appears in the Patent and Trademark Office 10 each participant need only be able to receive and send e-mail 

patent file or records, but otherwise reserves all copyright (which can be done using a wide variety of products, from 

rights whatsoever. numerous vendors.) The present invention fulfills this and 

BACKGROUND OF THE INVENTION other needs - 

The present invention relates generally to the area of SUMMARY OF THE INVENTION 

information processing and, more particularly, apparatus The present invention recognizes a user needs flexibility 

and methods for managing and scheduling time-based infor- in choosing how appointments, events, and other time-based 

mation for multiple individuals located at different locations. data are entered and managed, despite the fact that other 

Successful management of one's time is a goal that every individuals who need to participate might use other propri- 

successful professional must achieve. One's business day ^ etary software and reside in other time zones. According to 

may be swept away in a deluge of meetings and the present invention, therefore, an electronic group 

appointments, all of which must be somehow managed. An scheduling/calendar system is provided with methods for 

attempt to manage this task on paper, such as with a simple peer-to-peer group scheduling among users, including those 

wall calendar, is unworkable for all but the simplest of users who only have simple e-mail support (i.e., do not have 

schedules. More likely, such unsophisticated aids to man- ^ access to the group scheduling/calendar system itself), or 

aging one's time will lead to scheduling conflicts, missed even have no e-mail support. 

appointments, botched deadlines, and angry clients. According to the present invention, if a user is able to 
Oftentimes, it is necessary to schedule a group of people receive and respond to^ma^he or she should be able to 
for an event, such as a meeting. This is the problem of participate in group scheSulmgu) an automated fashion. In 
"group scheduling" — that is, notifying a group of people 30 particular, the present invention allows a user to undertake 
that a certain event is going to happen and receiving con- group scheduling with other "remote" users located at 
firmation from members of the group whether each can different locations (including those with different time 
participate. Conventionally, "group scheduling" has been zones), regardless of what particular platform or software 
largely limited to scheduling events for users within a applications each of the other users is employing. In contrast 
particular "work group." Typically, a "work group" has 35 to prior art scheduling approaches which required all users 
comprised those users connected together through a local to operate the same proprietary scheduling software, the 
area network (LAN). Alternatively, a "work group" can be present invention instead requires only one user of a work- 
extended to users who can receive messages. In this group to have the group scheduling software which" tfe 
extended group, however, manual processing on the part of present invention is embodied. Every other user need only 
the user is typically required. For instance, for a user who 40 be able to send and receive e-mail messages — using any one 
connects from a remote location, the user is required to of the wide variety of e-mail packages which are available — 
manually process messages received to manually update the in order to be automatically tracked by the system. Still 
calendaring product to update one's scheduling status infor- further, the present invention includes facilities for accom- 
mation. This leads to two disjointed activities for the user: modating even those users who cannot receive e-mail. 
(1) retrieving messages and (2) entering/processing sched- 45 "E-mail" itself is a messaging-based approach which is 
uling information. exploited by the present invention for communicating with 
With the ever increasing importance of the Internet, work all users, regardless of which proprietary system a given user 
groups are no longer confined to local area networks, or even is employing. The present invention implements a messag- 
wide area networks (WANs). Instead, people are connected ing subsystem or exchange which provide scheduling primi- 
together via electronic mail or "e-mail." At the same time, so lives (e.g., "accept" and "decline" message types) for sup- 
however, users have become accustomed to the ease which porting the basic functionality of group scheduling, even for 
automatic scheduling systems provide, such as those which generic e-mail clients — that is, a client which does not share 
operate within a proprietary environment (e.g., Novell nor is even aware of the group scheduling software sub- 
Group wise® operating on a Netware® local area network). system provided by the local client of the system of the 
If users are not connected to the same proprietary system 55 present invention. This include "dumb" remote clients 
(e.g., Novell Groupwise), then the users must resort to a which simply have no knowledge or understanding of the 
manual scheduling process. Here, the job typically falls to a scheduling format supported by the group scheduling local 
secretary or administrative assistant who must contact each client 

proposed participant individually, for oetermining his or her l n typical operation, for instance, group scheduling begins 

availability. Typically, the person charges with scheduling 60 with a user scheduling an event, that is, sending to desired 

the event must "negotiate" with the proposed participants for participants an initial meeting message or "invitation" for 

reaching a time when the meeting can finally happen. The scheduling the event. The event itself can K^an^MypTof 

process is still not complete, however. A confirmation mes- event, including those with a duration (e.g., meetings and 

sage must be sent to all proposed participants for confirming appointments); "resources" (e.g., conference rooms, 

the final time. & projectors, and the like) can also be scheduled. The recipient 

What is really needed are system and methods which user(s) can receive the message across a variety of different 

permit any user to schedule appointments with a group of software platforms or e-mail solutions. 
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The message itself comprises an identifier, such as <ISK> cess the reply message automatically, including entering the 

(or other unique), together with a scheduling invitation in appropriate information in the user's group scheduling cal- 

different formats. The different formats include, in order of codar. In this manner, the system of the present invention 

increasing content richness, a simple text embedded sched- C an support different levels of participation of various users 

uling invitation, an HTML (Hypertext Markup Language) 5 ( Done of which is required to have the system), throughout 

form embedded scheduling invitation, and a proprietary various stages of group scheduling 
binary "MIME** (Multipurpose Internet Mail Extensions) 

scheduling invitation. Each format is designed to transfer the BRIEF DESCRIPTION OF THE DRAWINGS 
highest degree of information content which a particular 

target client type can handle. A remote client having the 10 FIG. lAis a block diagram of a computer system in which 

scheduling system of the present invention can recognizes me P 1 ^ 111 invention may be embodied, 

from the identifier that the message is from another propri- FIG. IB is a block diagram of a software system of the 

etary client Accordingly, the client can process the binary present invention for controlling the operation of the system 

"MIME** scheduling invitation natively. This message is a of FIG. 1A 

vendor-specific message, allowing direct, proprietary com- 15 FIG. 2 is a bitmap screenshot illustrating a user interface 

munication between proprietary clients with the richest of a Personal Information Manager which embodies the 

possible information content. present invention. 

Since other clients have no knowledge of the scheduling FIGS. 3A-C illustrate interclient communication which 

system, they simply ignore the identifier and the binary employs a message incorporating multi-format information 

attachment. To allow the local client to communicate with 20 embedded within. 

these recipient, non-proprietary interclient communication A . ... « . ^ , 

F ♦ 1 j b • . 4 FIG. 4 is a bitmap screenshot illustrating a Deskpad 

formats are employed. For instance, a remote client with interface rovided b the te 

browser capability can employ the HTML form embedded . m " 

scheduling invitation, which can be appropriately processed RGS * 5A_I bitma P screenshots illustrating a Sched- 

by its Web browser (e.g., Microsoft Explorer or Netscape 25 ^8 Wizard interface provided by the system for schedul- 

Navigator); this represents the richest content that this client ing events - 

type can handle. The embedded HTML form (i.e., Web FIGS. 6A-C are bitmap screenshots illustrating a pre- 

page) can easily be viewed by the Web browser as an input ferred interface provided by the system for processing 

form having input fields corresponding to the information incoming event invitations. 

requested for scheduling the event For instance, the form 30 FIGS. 7A-C are bitmap screenshots illustrating a pre- 

may include text or input fields for subject, time, event, and ferred interface provided by the system for processing 

the like. Additionally, the form can include screen buttons mcoming replies. 

for allowing the recipient user to "accept" or "decline" the FIGS. 8A-G are bitmap screenshots illustrating a pre- 
mutation. At the conclusion of completing the input form, ferred interface provided by the system for scheduling use of 
the recipient user can select "submit" for returning the input 35 resources. 

information back to the initiator. Here, the browser of the n • u » j* ■ 

recipient generates a reply message, in a manner similar to - ™ G . 9 prOVK ^ f ovemew ° f * e 

that done today forTn-liTlntr^t registration. Upon "S^^SST ° f " ^ scbeduhD 8 of «» 

receipt of the reply, the originating client can identify, n ' 

decode, and process the reply appropriately. 40 RG 10 a block diagram illustrating the general process 

In the event that the recipient client is a simple e-mail of sendin S *** event 

client, the recipient client employs the simple messaging FIG. 11 is a block diagram illustrating the general process 

format incorporated into the scheduling message. Here, the of reoe i vin S messages. 

recipient client can view a plain text e-mail message to FIGS. 12A-C are bitmap screenshots illustrating receipt 

which the user can respond (e.g., "accept" or "decline"). In 45 of an e-mail scheduling invitation by a recipient whose 

the recipient client's reply, the client includes the "body" of system represents a non-SK client without browser support, 

the initial invitation message. As is common in e-mail FIG. 13 is a screenshot illustrating receipt of an e-mail 

communication, the reply message can itself easily incor- scheduling invitation by a recipient whose system represents 

porate the contents of the original message. By simply a non-SK client with browser support, 

including the initiator's original message when a non-SK 50 

client replies, the non-SK client is incorporating information DETAILED DESCRIPTION OF A PREFERRED 
which facilitates processing of the reply by the SK local EMBODIMENT 
client. For instance; the reply includes the W ISK** signature The following description wfll-focus on Uhe -presently 
which is embedded within the subject line. Other informa- preferred embodiment of the present invention, which is 
tion includes the e-mail address of the recipient as well as 55 operative in an end-user application running under the 
the recipient's response (e.g., "accept") using delimited key Microsoft® Windows environment. The present invention, 
words. Upon receiving the reply, the initiator can recognize however, is not limited to any particular one application or 
that the response (e.g., an "accept" message or a "decline** any particular environment Instead, those skilled in the art 
message) corresponds to a particular invitation send out, will find that the system and methods of the present inven- 
tus facilitating decoding and processing of the message. In 60 tion may be advantageously applied to a variety of system 
this manner, the response includes sufficient scheduling and application software, including database management 
information embedded within it to allow the initiator client systems, wordprocessors, spreadsheets, and the like, 
to appropriately decode the response, despite the fact that the Moreover, the present invention may be embodied on a 
responding recipient is a simple e-mail client without variety of different platforms, including Macintosh, UNIX, 
browser capability. 65 NextStep, and the like. Therefore, the description of the 
Regardless of which format the recipient employs, the exemplary embodiments which follows is for purposes of 
group scheduling system of the present invention can pro- illustration and not limitation. 
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System Hardware 

The invention may be embodied on a computer system 
such as the system 100 FIG. LA, which comprises a central 
processor 101, a main memory 102, an input/output con- 
troller 103, a keyboard 104, a pointing device 105 (e.g., 
mouse, track ball, pen device, or the like), a display or screen 
device 106, and a mass storage 107 (e.g., bard or fixed disk, 
removable floppy disk, optical disk, magneto-optical disk, or 
flash memory). Although not shown separately, a real-time 
system clock is included with the system 100, in a conven- 
tional manner. Processor 101 includes or is coupled to a 
cache memory 109 for storing frequently accessed informa- 
tion; memory 109 may be an on-chip cache or external cache 
(as shown). One or more input/output device(s) 108, such as 
a printing device or slide output device, are included in the 
system 100, as desired. As shown, the various components 
of the system 100 communicate through a system bus U0 or 
similar architecture. 1 In a preferred embodiment, the system 
100 includes an IBM PC-compatible personal computer, 
available from a variety of vendors (including IBM of 
Armonk, N.Y.). I/O device 108 may include a laser printer, 
such as an HP Laserjet printer, which is available from 
Hewlett-Packard of Palo Alto, Calif. 
System Software 

A Overview 

lllu&trateci in FIG. IB, a computer software system 120 is 
provided for directing the operation of the computer system 
100. Software system 120, which is stored in system 
memory 102 and on storage (e.g., disk memory) 107, 
includes a kernel or operating system (OS) 140 and a 
windows shell 150. One or more application programs, such 
as client application software or "programs" 145 may be 
"loaded" (i.e., transferred from storage 107 into memory 
102) for execution by the system 100. 

System 120 includes a user interface (UI) 160, preferably 
a Graphical User Interface (GUI), for receiving user com- 
mands and data. These inputs, in turn, may be acted upon by 
the system 100 in accordance with instructions from oper- 
ating module 140, windows 150, and/or client application 
module(s) 145. The UI 160 also serves to display the results 
of operation from the OS 140, windows 150, and application 
(s) 145, whereupon the user may supply additional inputs or 
terminate the session. OS 140 and windows 145 can be 
provided by Microsoft® Windows 95, by Microsoft® Win- 
dows NT, or by Microsoft® Windows 3.x (operating in 
conjunction with MS-DOS); these are available from 
Microsoft Corporation of Redmond, Wash. Although shown 
conceptually as a separate module, the UI is typically 
provided by interaction of the application modules with the 
windows shell, both operating under OS 140. 

One application software comprises a Personal Informa- 
tion Management (PIM) System 125 which includes an 
Internet-based Group Scheduling Module 127 of the present 
invention. The Internet-based Group Scheduling* Module 
127 provides group scheduling among users connected to 
the Internet or to other commercial service providers (e.g., 
CompuServe). In an exemplary embodiment, PIM System 
125 comprises Sidekick®, which is available from Starfish 
Software, Inc. of Scotts Valley, Calif. A general description 
of the operation of Sidekick® can be found in its accom- 
panying user manual. Interface and methods provided by the 
group scheduling module of the present invention, in the 
exemplary embodiment of Sidekick®, will now be 
described in further detail. 
Peer-to- Peer Scheduling 

A. General 

According to the present invention, if a user is able to 
receive and respond to e-mail, be or she should be able to 
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participate in group scheduling. In particular, the present 
invention allows a user to undertake group scheduling with 
other "remote" users located at different locations (including 
those with different time zones), regardless of what particu- 

5 lar platform or software applications each of the other users 
is employing. In contrast to prior art scheduling approaches 
which required all users to operate the same proprietary 
scheduling software, the present invention instead requires 
only one user of a workgroup to have the group scheduling 

to software which the present invention is embodied Every 
other user need only be able to send and receive e-mail 
messages — using any one of the wide variety of e-mail 
packages which are available. Still further, the present 
invention includes facilities for accommodating even those 

is users who cannot receive e-mail. 

"E-mail" itself is a messaging-based approach which is 
employed by the present invention for communicating with 
all users. The present invention implements a messaging 
subsystem or exchange which provide scheduling 

20 primitives — for example, "accept** and "decline" message 
types — for supporting the basic functionality of group 
scheduling. In typical operation, for instance, group sched- 
uling begins with a user scheduling an event, that is, sending 
to desired participants an initial meeting message or "invi- 

25 tation" for scheduling the event The event itself can be any 
type of event, including those with a duration (e.g., meetings 
and appointments); as described below, "resources'* (e.g., 
conference rooms, projectors, and the bice) are also sched- 
uled. The recipient user(s), once having received the 

30 message, can undertake one of several actions. The user can 
accept or decline to participate, or the user can forward the 
message to one or more other users. When declining a 
proposed scheduling event, the user can propose another 
time for the event. When a user declines, he or she replies 

35 with a "decline" message; the message may include one or 
more alternative times proposed by the declining user The 
decline message is processed upon its return, whereupon the 
system automatically updates the scheduling calendar. An 
accepting user, on the other hand, replies with an "accept" 

40 message. Again, the group scheduling system processes the 
message automatically, including entering the appropriate 
information in the group scheduling calendar. In this 
manner, the system of the present invention can support 
different levels of participation of various users (none of 

45 which is required to have the system), throughout various 
stages of group scheduling. 
B. Functional Overview 

FIG. 2 is a block diagram illustrating a functional over- 
view of a group scheduling system 200 of the present 

50 invention, from the perspective of an end user. The system 
includes a local client 210 comprising front-end software, 
including a graphical user interface, for entering scheduling 

- • information and generating group scheduling messages. The 
client 210 connects to transport mechanism or messaging 

55 engine 220. This provides the mechanism whereby the client 
210 can send messages to and receive messages from remote 
clients. 

In a preferred embodiment, the messaging engine 220 
supports Microsoft is Exchange or MAPI (Messaging Appli- 

60 cation Programming Interface), AOL (America On line), 
and POP 3 (Internet "Post Office Protocol)" messaging 
protocols. These widely-supported protocols can be 
employed for reaching remote clients having addresses (i.e., 
accounts) on the Internet, America On Line, Microsoft 

65 Network (MSN), as well as other systems which are acces- 
sible through gateways (e.g., Compuserve, which has an 
Internet gateway). To further support each messaging or 
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mail system, the client 210 includes an address book module the local client (i.e., recipient SK remote clients) can rec- 

230, which comprises a separate address book for each ognize the identifier and readily identify the message as a 

messaging system. In an exemplary embodiment, for scheduling message from another SK client. This allows all 

instance, me system provides support for AOL address book, SK clients to easily identify scheduling messages among 

Internet (Netscape) address book, and MAPI-exchange 5 themselves, thus facilitating decoding and processing of 

address book. messages. In the instance of one SK client communicating 

With the messaging engine connection, the client 210 is a with another SK client, therefore, the recipient is a "smart" 

"local" client which exchanges messages with various client with full knowledge and understanding of the type of 

"remote" clients, such as client 240, client 250, and client message and how to interpret it 

260. As shown, there are different types of remote clients. 10 One such SK-client-to-SK-client dialog is illustrated by 
One type of remote dient-is^qne wiuch..shares.J^ .same _ interclient communication 300 in FIG. 3 A. Local SK client 
software group scheduling subsystem as the local client 210 sends e-mail message 310. The message comprises the 
(i.e., it "understands" proprietary file formats of the local <ISK> (or other unique) identifier 311 together with a 
client 210). Such a client is shown at 240. Here, the local scheduling invitation in different formats. The different 
client 210 and the remote client 240 can of course commu- is formats include, in order of increasing content richness, a 
nicate directly using the proprietary format understood by simple text embedded scheduling invitation 313, an HTML 
both/is the same manner as presently done by present-day (Hypertext Markup Language) form embedded scheduling 
proprietary group scheduling solutions. invitation 315, and a proprietary binary "MIME" 
According to the present invention, however, a remote (Multipurpose Internet Mail Extensions) scheduling in vita- 
client may also comprise a generic e-mail client — that is, a 20 lion 317. 

client which does not share nor is even aware of the group Each format is designed to transfer the highest degree of 

scheduling software subsystem provided by the local client information content which a particular target client type can 

of the present invention. These "dumb" remote clients, such handle. In FIG. 3A, for instance, remote client 320 recog- 

as represented by clients 250 and 260, simply have no nizes from the identifier 311 that the message 310 is from 

knowledge or understanding of the scheduling format sup- 25 another SK client — SK local client 301. Accordingly, the 

ported by the local client 210. For clarity of the description remote SK client 320 processes the binary "MIME" scbed- 

which follows, the generic or non-proprietary clients are uling invitation 317.This message is a SK-specific message, 

referred to as "non-SK" clients, for indicating that these allowing direct, proprietary communication between SK 

clients do not have Sidekick® — the proprietary software clients with the richest possible information content, 

which implements automated group scheduling with both 30 Description of the MIME format is well documented in the 

proprietary and non-proprietary clients. Those clients which trade literature; see e.g., Kientzle, T., MIME and Internet 

do have Sidekick® are referred to a "SK" clients. Mail, Dr. Dobb's Journal, September 1995, pp. 54-60 (with 

With the ever-increasing use of the Internet and particular code listings pp. 104-110), the disclosure of which is hereby 

the rapid adoption of the World-wide Web ("Web") as a incorporated by reference. 

pervasive communication platform, an ever-increasing num- 35 Since non-SK clients have no knowledge of the schedul- 
ber of non-proprietary remote clients will have a standard ing system, they simply ignore the identifier and the SK 
browser, such as Netscape Navigator (available from binary attachment To allow the SK local client to commu- 
Netscape of Mountain View, Calif.) or Microsoft Internet nicate with these non-SK recipient, the non-proprietary 
Explorer (available from Microsoft Corp. of Redmond, interclient communication formats 313, 315 are employed. 
Wash.). As described in further detail below, the present 40 As shown in FIG. 3B, for instance, remote non-SK client 
invention may exploit this by using rich text messages, such with browser 340 employs the HTML form embedded 
as e-mail including one or more HTML (Hyper Text Markup scheduling invitation 315, which can be appropriately pro- 
Language) forms or "Web pages." Such a client, such as cessed by its Web browser (e.g., Microsoft Explorer or 
shown at 250 in FIG. 2, is identified as a remote non-SK Netscape Navigator); this represents the richest content that 
client "with browser." A simple e-mail client, on the other 45 this client type can handle. 

hand, is identified as a remote non-SK client "without The ^embedded HTML form (i.e^ Web page) can easily be 

browser." viewed by the Web browser as an input form having input 

C. Interclient Communication fields corresponding to the information requested for sched- 

The local SK client communicates with other clients by uling the event. For instance, the form may include text or 

employing its messaging engine or transport layer to sends 50 input fields for subject, time, event, and the like, 

and receives electronic mail or messages. As illustrated in Additionally, the form can include screen buttons for allow- 

FIGS. 3A-C, each message itself is structured to facilitate an ing the recipient user to "accept" or "decline" the invitation, 

optimahcommimication protocol appropriate for the differ* At the conclusion of completing- the input form; the recipient - 

ent types of clients (i.e., SK client, non-SK client with user can select "submit" for returning the input information 

browser, or non-SK client without browser). This is 55 back to the initiator. Here, the browser of the recipient 

achieved by incorporating into the message different formats generates a reply message, in a manner similar to that done 

of the scheduling message — one format for each particular today for on-line Internet registration. Upon receipt of the 

client type. reply, the SK client 210 can identify, decode, and process the 

To allow rapid identification of scheduling messages reply appropriately. Based on the action selected by the 

between SK clients themselves, an identifier or "signature" 60 recipient (e.g., accept, decline, or the like), the SK client 210 

is incorporated into the message by tagging the standard can update its scheduling information in an appropriate 

"subject line" in each e-mail message. In an exemplary manner. 

embodiment, the initiator of a message (i.e., local SK client) In the event that the client is^npn^SK client and does not 
includes the following unique identifier in the subject line of have a browser, a simple messaging format is employed. As " 
<ISK> or, alternatively, <SIS>. The interpretation of this 65 shown in FIG. 3C, remote non-SK client without browser 
depends on the actual type of client the recipient is. Remote 360 processes the simple text embedded scheduling in vita- 
recipient clients which do support the proprietary format of tion 313, as this represents the richest content that it can 
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handle. Here, tbe recipient client receives a plain text e-mail The interface 400 provides different "views": Calendar 

message to which it can respond (e.g., "accept" or view, Cardfile view, Write view, Expense view, and Activi- 

a dec line"). In the client's response, the client includes the ties view. The Cardfile view can be used as an address book 

"body" of the initial invitation message. As is common in in which the user stores names, addresses, e-mail addresses, 

e-mail communication, the reply message can itself easily 5 phoDe numbers, and other information (e.g., record 

incorporate the contents of the original message. By simply collection). The Cardfile works with the Calendar's Internet 

including the initiator's original message when a oon-SK scheduling to address event invitations, and also can 

chent replies, the non-SK chent is mcorr^ra^g^ormaUon iook ^ numbers of incoming calls using Caller ID. 

which facilitates processing of the reply by the SK local ^ ^ ^ ^ ^ Cardfile ^ £ e Pbon 7Sal er to dial 

chent. For instance, the reply includes the ISK signature n , . c . „ . ~ . . 

which is embedded within the subject line. Other infbrma- 10 °L m ^ ^ onn *™ ml ° a lctter ^ 

tion includes the e-mail address of the recipient as well as Y ™ c Wnte ™ P™** * P^**^**^ format 

the recipient's response (e.g., "accept") using delimited key documents, organized in folders and binders. The Expense 

words. Upon receiving the reply, the initiator can recognize view lets ^ enter ^formation from expense receipts, 

that the response (e.g., an "accept" message or a "decline" **** or S amze expenses in folders. The user's expenses are 

message) corresponds to a particular invitation send out, 15 printed in a finished expense report. The Activities view 

thus facilitating decoding and processing of the message. In presents information about all the user's group scheduling 

this manner, the response includes sufficient scheduling events phis other Calendar activities: one's calls, To -Do •« 

information embedded within it to allow the initiator client items, and individual appointments for the period selected, 

to appropriately decode the response, despite the fact that the The Activities view is employed to reply to group event 

responding recipient is a non-SK client without a 20 invitations and view replies to group events the user has 

browser — a simple, generic e-mail client originated. 

D. Resource Scheduling Of particular interest to the present invention is the 

When a meeting or an event is scheduled, often Calendar view which, as shown in FIG. 4, displays the user's 

"resources" will be needed as well. For a board meeting, for Calendar. Here, the user creates^ipp»intments and uses 

instance, the board room needs to be available. The meeting 25 Internet-based messaging (or other electronic messaging 

might also require other resources, such as an overhead service) to automatically handle invitations and replies for 

projector or a VCR. In accordance with the present scheduling group events. The appointments adjust to the 

invention, the scheduling system is extended to include user's own local time zone, if the user travels with the 

these "resources." As with users, the resource scheduling is computer when he or she switches to the new local time in 

peer-to-peer — that is, it is shared among the users in a 30 an "EarthTime" module of the system. The EarthTimc 

cooperative fashion. module tells the user the current time in eight locations 

A resource itself "owns" an e-mail account — that is, it is around the globe, and provides other information such as 

able to send and receive scheduling messages. In this time difference start and end of daylight saving time, and 

manner, scheduling of the resource can be completely auto- other facts about each city, for over 540 cities. Further 

mated. Here, the resource is controlled by an SK client, 35 description of the EarthTime module is provided in 

which manages the calendar for the resource. When a commonly-owned application Ser. No. 08/609,983, filed 

request is received to schedule the resource, the SK client Feb. 29, 1996, which is hereby incorporated by reference, 

can check its calendar and respond whether the resource is When desired, tbe user can print the Calendar in a variety 

available, all in an automated fashion. For the example of a formats, including page sizes suited to the most popular day 

board room meeting, the board room resource is, in effect, 40 planners, such as Keith Clark, DayRunner, Day-Timers, and 

"invited" to the meeting. Through the SK client which is Franklin Planner, 

controlling the scheduling calendar for tbe board room, the B. Peer-to-Peer Scheduling Interface 

board room can "reply." In a preferred embodiment, an 1. Overview 

immovable resource (e.g., "room" resource) cannot be The Group Scheduling module 127 uses electronic mes- 
scheduled to attend two meetings at the same time. A person, 45 saging to communicate with others to schedule events and 
on the other hand, can be scheduled for two meetings at the book resources. Because it supports numerous e-mail 
same time; in that instance, the person decides which platforms, including the Internet, the module can provide 
meeting to attend (Le., which one is more important), or group scheduling with users anywhere in the world. The 
decides to attend certain portions of each meeting. system automatically invites the participants to an event the 
Preferred Interface and User Operation so user schedules, and collects their replies for accepting or 
A. General Interface declining the invitation or for requesting that the user 
As shown in FIG. 4, tbe system provides a "Deskpad" reschedule it. Hie event is automatically placed in the 
interface 400 — that is, a personal information management' - Calendar- in the Calendar view, as well as the recipients' ^ 
interface which includes an electronic appointment calendar. calendars if they accept. Additionally, the user can also. 
The interface 400 includes a menu bar ,410, for invoking 55 automatically reserve resources for the event, such as con- 
menu items or commands. The interface itself is comprised fere nee facilities, projectors, and others. Most of the group 
of particular subregions. A first subregion 420 displays the scheduling occurs in the Activities View, where the user can 
current time and date. Below this region are a To Do region see all group events in list form. Events the user schedules, 
430 and a Call region 440. The former lists IgJGjo jtems or that the user accepts an invitation to, are also posted 
which the user has included. The latter is a log of calls which 60 automatically in the user's Calendar, 
the user wishes to track. Actual schedule events or appoint- To schedule an event, the user enters the jdetails_of the_ 
merits are displayed in the interface at region 450,^ By meeting and the list of people he~or she" wants toJnvite/The 
default, appointments are displayed in one's own local time. system then automatically nouses me recipients and collects 
The interface also includes a quick lookup or viewport 460, their responses for tbe user. In addition to electronic 
for working with another view of the interface (e.g., "Card- 65 messaging, the user can use fax or telephone for group 
file" view). Finally, the interface includes Deskpad icons scheduling, for people without e-mail accounts. If the user 
470, for quickly switching to other modules of the system. specifies a fax number for notification, the event invitation 
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is automatically sent using built-in fax software (e.g., Web) to add an Internet address as part of the message 

Microsoft Fax) and the user's fax modem. Selecting phone information. Users receiving the URL can click on it to 

notification, on the other hand, puts a reminder in the user's launch their Web browser and jump to the URL site. At 543, 

Calls list the user can select a file to send as an attachment to the 

2. Scheduling Wizard 5 meeting invitation. The user proceeds to the next pane by 

The system provides a convenient "Scheduling Wizard" selecting Next button 544. The next pane or page is the 

to assist the user in the process of entering event informa- "Resources" page, illustrated in FIG. 5G, where the user 

tion. It helps the user enter all the information about the selects one or more resources from a list 551 of available 

event, and identify the participants he or she wants to invite. resources. The user clicks the selection buttons 553 to add or 

The user also can create a group event using a "Schedule an 10 remove items from the Event Resources list 552. By clicking 

Event" dialog box. The user can include a message with the Next button 554, the user proceeds to the next page, 

invitation, and the replies can include a message and a report The next page is the "Event options" page, illustrated in 

on free time if a recipient cannot attend at the scheduled FIG. 5H. At 561, the user can select a check box to send a 

time . If the user needs to ootify some people by fax or phone, reminder as well as set an amount of advance notice. By 

he or she can enter their reply status manually. is checking "Page Me" or "Alert Me" and setting a time, the 

The easiest way to enter group event information is using user can instruct the system to remind the user by page or 

the Scheduling Wizard. To schedule an event in the- Activi- alarm. The user selects the RSVP radio button, in Event 

ties or Calendar view, the user selects Interoet|Scheduling Options box 562, to request a reply, or selects the FYI radio 

Wizard from the main menu, as shown at 501 in FIG. 5A button to send an announcement only. By selecting RSVP 

This action launches Scheduling Wizard 510, as shown in 20 (i.e., "please respond"), recipients can send back a reply 

FIG. 5B. The wizard consists of a series of pages that prompt whereupon the system automatically collects the informa- 

the user to enter the information for the event, such as tion for the user. If the user chooses FYI (i.e., "For Your 

participants, resources, agenda or notes, and options. The Information"), on the other hand, he or she is sending an 

user enters the information in each page, and clicks "Next" announcement of the event, without requesting replies. This 

to proceed to the next page. The user can go back at any time 25 option is used, for example, for events such as a company 

to earlier pages if be or she needs to change something. meeting that will occur regardless of individual schedules. 

When the user has finished, they system displays an Event Additionally, in Event Options box 562, the user can instruct 

Summary. Here, the user can review his or her choices, and the system to enter this Event in the user's Contact Log. 

make changes, if necessary, by going back to previous Upon checking the box, the event is entered in the Contact 

pages. When the user is ready to schedule the event, the 30 Log for each participant in the invitation list Finally, the 

Wizard adds it to the user's queue of outgoing messages, and user can specify a type for the event: Public, Personal, or 

put it on the user's calendar. To use Internet scheduling, the Confidential. 

user creates a cardfile that contains properly identified Upon selecting Next button 563, the user instructs the 

e-mail addresses for the people the user will be inviting. system to proceed to the "Schedule the Event" page, illus- 

Altematively, the user can use an existing Netscape Address 35 trated in FIG. 51. Here, the user can review the selections, at 

Book or Microsoft Exchange Cardfile for addressing. 571, and go back to any previous page, if needed. Once 

The wizard is used from start to finish as follows. First, satisfied with the selections, the user selects "Finish" button 

the user enters an event type. As illustrated in FIG. 5C, the 572 to schedule the event. Alternatively, the user can cancel 

user clicks an event category at 511 and selects a particular the input altogether by selecting "Cancel." 

subject — that is, an event type to schedule. When the user 40 The user can also include people who do not have e-mail 

has completed each Wizard panel, the user clicks "Next" in the list of event invitees. Here, two options exist for 

button 512 to continue. Alternatively, the user can click addressing invitations: fax or telephone. If an invitation is 

"Back" to return to an earlier panel. Next, in FIG. 5D, the directed to someone at their fax address, the system launches 

user invokes the "Date and Time" page. Here, the user the fax software (e.g., Microsoft Fax) and faxes the invita- 

reviews the subject presently entered, at 521, and then enters 45 tion automatically. If the user selects someone's telephone 

a date and time for the event, at 522. The user can select the number as their address, a reminder is added to the user's 

date by typing or by using the arrows, A calendar can be Calls list in the calendar to call that person. When the user 

opened at this point (e.g., by selecting the large arrow). The hears from these people, he or she can enter their meeting 

user also enters the start and end times. Next, the user selects reply by entering the appropriate status: Accept, Decline, 

or types the city where the event is to occur, at 523. The time 50 Reschedule Request, or Delegate, 

zone fills in automatically. After typing or selecting a place, 3. Incoming Event Invitations 

the user advances the wizard to the next pane by selecting When the user receives an invitation to an event, it 
Next button 524. ...... ww^vw* +z appears in bold type in the 'Activities view 600, which is 

The next pane is a "Participants" page, illustrated in FIG. illustrated in FIG. 6A. An icon appears in the News column 

5E, which allows the user to select participants. At 531, the 55 623 to indicate a new event. The user will see the incoming 

user chooses an Address Book or a mailing list; clicking event invitation in his or her e-mail in-box, marked with the 

"More" opens a different Address book. Now, the user clicks signature (e.g., <ISK> for Internet Sidekick) in the subject, 

the folder next to each name, and clicks the notification In typical operation, the user disregards this message in his 

method (i.e., e-mail, fax, or the like) for that participant The or her e-mail in-box, as the system will automatically find 

user adds desired selections to the Participants list 533 or CC 60 and handle it for the user. Users who have other systems, on 

list 534, using selection buttons 535. Thereafter, the user the other hand, can open the message like any other e-mail; 

moves to the next pane by selecting Next button 536. On the it contains instructions on how to reply so the original 

"Message" page, shown in FIG. 5F, the user types the sender's system (i.e., SK client) will be able to record the 

agenda or notes, at 541 . From buttons 542, the user can click reply. 

a "Message" button to select a file containing a message. 65 To get to the Activities view, the user click the Activities 

Alternatively, the user clicks "Attach URL" (Uniform icon (or selects the corresponding menu command). After 

Resource Locator, toe address of a site on the World Wide the user has clicked Group Events tab 611, status informa- 
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lion is displayed for group events in the three left-band 
columns. Type column 621 displays an icon for the event 
type: (b 1) New event the user initiated; (2) New incoming 
event, and (3) Incoming event the user has opened. News 
column 623 displays an icon for all new items: (1) New 
event information; (2) Reply has arrived; and (3) Event has 
been canceled. Out-box column 625 indicates messages that 
are queued to be sent during the user's next e-mail flash 
session; it displays an icon indicating Messaging waiting to 
be sent. The user can select an Internet |Send/Receive Now 
command to send pending messages immediately. By click- 
ing on a Detail item 627, the user can display further 
information in Details and Information pane 629. 

To reply to an event invitation, the user reviews the event 
specifics in the Details and Information panes. Then, the user 
clicks a choice to reply from the buttons at the bottom of the 
window (e.g., "Accept,** "Decline,** "Reschedule,' 1 or the 
like). Alternatively, the user can right-click an event in the 
top pane, and choose from a Shortcut menu. In a preferred 
embodiment, the user's reply is sent only to the originator, 
not to others invited to the event. 

Accept button 631 lets the user enter a short reply 
message (via Reply dialog 635 in FIG. 6B), and then sends 
the acceptance to the initiator confirming that the user will 
attend. The event is automatically added to the user's 
calendar. Decline button 633, on the other hand, sends a 
reply message to the initiator that the user will not be able 
to attend. The event is not added to the user's calendar. With 
the user's reply, the user can include a Free Time report 
showing the user's booked and unbooked time for the next 
30 days (or other user-specified interval), for assisting the 
meeting originator in rescheduling. Included in the Free 
lime report is an indication of all the times for the next 30 
days when the user has a scheduled event, and all other (free) 
times. In a preferred embodiment, no information about 
specific events on the user's calendar is sent, beyond the 
indication that the time is booked. The user checks box 637 
to include the report. 

In addition to accepting or declining, the recipient user 
can request rescheduling of the event. Here, the user selects 
Reschedule Request button, such as button 635 in FIG. 6A. 
In response, the system displays Reschedule Request dialog 
640, as shown in FIG. 6C. This option sends a reply 
requesting that the event be moved to another time or date. 
In the dialog, the user can enter one or more alternate times 
for the event, as well as include a short message. As with the 
decline response, the user has the option of including a Free 
Time report to assist the meeting originator in rescheduling. 
The Minutes button 634 is used to send notes or minutes to 
all participants. This launches a "Compose the Minutes'* 
window where the user can write a message or attach a file 
(by clicking a Browse button); the minutes are automatically 
distributed to the participants. - - - : - 

Besides accepting and declining, the user can "delegate" 
the event by choosing the option from the menu. The option 
opens a Delegate To dialog box (not shown), where the user 
can specify a person to forward the invitation to. Here, the 
meeting originator is notified that the user has delegated the 
event to someone else. 

4. Replying to Incoming Event Invitations for Non-SK 
Clients 

Users who are non-SK client users (i.e., do not have 
Internet Sidekick installed) can still reply to incoming 
invitations in a way that is automatically recorded by the 
event originator's. All event invitations, whether the recipi- 
ent is a non-SK client user or an SK client user, appear in the 
user's e-mail in -box. Users who are SK client users can 
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ignore the messages, since the system will read and process 
these automatically. 

Non-SK client users can open the invitation like any other 
e-mail item and read the contents, which are stored in 

5 formatted text. The body of the message includes instruc- 
tions that explain briefly bow a non-SK client user can reply. 
To reply to an invitation using conventional e-mail software, 
the non-SK client user proceeds as follows. The user opens 
the invitation in his or her e-mail in -box, like any other 

10 message. Using the user's own e-mail software (from any 
vendor), the user "replies" to the message, and includes the 
body of the original message in the reply (i.e., does not 
modify the contents). The subject field of the reply will 
already include <ISK> indicating that the reply is an Internet 

is Sidekick scheduling message. In the body of the message, 
the user finds a section labeled "Your Reply." Here, the user 
simply types an "X" in the brackets next to Accept or 
Decline, so that the reply reads "[X] Accept" or "[X] 
Decline"; the replying user can also type a brief message in 

20 the space between the markers reading <B£GIN REPLY 
MESSAGE> and <END REPLY MESSAGE>. Now the user 
simply sends the reply. The originator's SK client will be 
able to process the reply automatically and mark the appro- 
priate status for that recipient. 

25 5. Incoming Replies 

The originator's SK client automatically collects reply 
messages from people which were invited to an event and 
displays the replies in the Activities view. As replies arrive, 
the user is notified by an icon in the News column (623 in 

30 FIG. 6A). The user can click the participants' names in the 
Activities view, and read their reply status, as well as any 
reply message they may have sent, in the Details and 
Information dialog 700, shown in FIG. 7 A. By clicking the 
+ sign by the participants in Details pane 701, the user can 

35 expand the list. By clicking a participant, the user can view 
the reply message in Information pane 703 and expand the 
Details and Information panes to full-screen, as desired. 

The originator user can reschedule an event which be or 
she originated by selecting the event and clicking Resched- 

40 ule button 711. This action displays a "Schedule an Event" 
dialog box where the user enters the new date and time 
information, and any other changes. The user is asked if be 
or she wants to notify all participants and resource managers 
about the change. If the user selects "Yes," notification is 

45 automatically sent 

In a similar manner, the user can cancel an event he or she 
originated by selecting the event and clicking Cancel Event 
button 713. The user will be asked to confirm that be or she 
wants to cancel the event and notify all participants; select- 
so ing "Yes" cancels the event Alternatively, the user can 
delete group scheduling events in the Activities view to 
clean up his or her events list. This is done by selecting one 
or more events and pressing the Del key, or by right-clicking 
an event and choosing Delete from the menu. In contrast to 

55 canceling, the action of deleting group events in the Activi- 
ties view does not remove them from the user's calendar, 
and does not notify meeting participants. It is used only to 
clean up the Activities list display. To delete a group event 
the user has originated and notify participants, the user 

60 clicks the Cancel Event button 713 or deletes the event in his 
or Calendar. 

Also in the Details and Information dialog 700, the user 
can elect to send a reminder to all event participants in 
advance of a meeting. This is done by selecting the event and 
65 clicking Send Reminder button 715. Alternatively, the user 
can arrange for the reminder when the user initially creates 
the event 
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If the recipient attaches a Free Time report (e.g., wbeo 
declining or requesting rescheduling of the invitation), his or 
her Free Time report appears with the reply message, as 
indicated by Free Time button 721 in FIG. 7B. The Free 
Time report shows when the recipient has events booked and 
what times are free, during the next 30 days, as described 
above. It can be viewed by clicking on the Free Time button 
721, whereupon the system displays Free Time report 723, 
for the reply. The report is useful in determining an alternate 
meeting time, especially when scheduling several people. 

6. Entering Replies Manually 

For people who are invited by fax or phone, the user can 
enter the reply status manually. To enter reply information 
manually, the user selects the event from the list (in the 
Activities view). Next, the user selects the participant's 
name to bring up that individuals details in the Details pane. 
Now, the user can enter the status by right-clicking on the 
participant's name, to bring up pop- up menu 740, shown in 
FIG. 7C. Here, the user can enter: "Accepted," "Declined," 
"Reschedule Requested," "Delegated," or "No Reply Yet." 

C. Resource Scheduling Interface 

1. General 

Resources are facilities such as conference rooms or 
equipment that the user wants to be able to schedule. The 
system of the present invention groups resources in one of 
the following resource types: 

1. Facilities — a resource such as a conference room or 
other immovable location. Facilities can have a Maxi- 
mum Occupancy setting. The system maintains a cal- 
endar for facilities and confirms or denies bookings 
automatically based on the calendar. 

2. Equipment — a movable resource such as a projector or 
vehicle. The system m aintains, a calendar for equipment 
and confirms or denies bookings automatically based 
on the calendar. 

3. Other — private resource which an individual user 
wants to keep track of, such as booking a conference 
call operator, or ordering catering for a meeting. There 
is no calendar for this category, and entries are recorded 
under the user's To Do items. 

Since resources typically do not have their own e-mail 
accounts, each resource has a "manager," whose e-mail is 
used to handle the calendar and messaging for reserving the 
resource. Typically, the manager is the person who creates 
the resource in the system of the present invention. Using the 
e-mail account of the manager, the system handles resource 
scheduling automatically in the background; the manager is 
not involved in these transactions. Alternatively, a resource 
can be given a dedicated e-mail account, whereupon the 
system uses it for automated scheduling of that resource. 
Once a resource has been added to the e-mail system (either 
to its own e-mail account or that of another's), it is distrib- 
uted to others to make it available to them for booking. 

2. Reserving a Resource 

The user can request a resource reservation as part of 
creating a group event However, the user may want to do it 
separately, in advance, so he or she can be sure the resource 
is available before sending meeting invitations. To reserve a 
resource without scheduling the event, the user employs a 
Reservation Wizard of the present invention, which will now 
be illustrated. 

To reserve a resource such as a conference room or 
projector using the wizard, the user selects 
Interne t|Reservation Wizard from the system menu. This 
displays the first Resource Reservation Wizard dialog 800, 
Step 1 (Facilities and Equipment), as shown in FIG. 8 A. The 
dialog lists resources which have already been distributed to 
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the user (and others), or have been created by the user. Here, 
the user chooses the facilities and equipment he or she wants 
to reserve by selecting each item. The user can reserve 
multiple resources by clicking each one. By clicking Details 
5 button 801, the user can see detailed information about a 
selected resource. When finished selecting resource, the user 
clicks "Next" button 803, to proceed to the next wizard 
dialog. 

The second Resource Reservation Wizard dialog 810, 
Step 2, is illustrated in FIG. 8B. In Step 2 (Purpose and 
Tune), the user enters the time and purpose for reserving the 
resource. When finished with Step 2, the user clicks Finish 
button 815. Based on the user's inputs, the Reservation 
Wizard sends out a request to book the resource for the time 
specified. The request is sent to the computer of the 

15 resource's manager (via e-mail account) for processing by 
the SK client. A reply message is sent back to the requestor's 
computer automatically, without requiring any action by the 
resource's manager. If the resource is available, the reply 
message confirms the reservation. If the resource is 

20 unavailable, a message listing available times is sent instead. 
In this case, the user can reschedule by again choosing 
Interne t|Resources(Reservation Wizard and changing the 
times as needed before re-sending the request. 

3. Adding and Distributing Resources 

25 The person who is going to manage the resource is usually 
the one who adds it using an Add command. This is selected 
from the system menu by choosing Interne t|Resources|Add . 
In response, the system displays Add Resources dialog 820, 
illustrated in FIG. 8C. Here, the user enters the name of the 

30 resource together with the e-mail type and account infor- 
mation; the latter two are automatically picked up from 
existing user preferences. The phone number field and other 
fields are included for convenience in case others have 
questions about resource reservations. The process is com- 

35 pleted by selecting Add button 821. 

After a resource has been added, it can be distributed. 
"Distributing" a resource is the process of making it avail- 
able to others for reserving. The manager distributes it to the 
users who will be reserving it. Anyone to whom the resource 

40 is distributed can distribute it to additional users. To distrib- 
ute a resource to other users, the user selects a Distribute 
command from the menu. In response, the system displays 
Distribute Resources dialog 830, illustrated in FIG. 8D. At 
831, the user clicks one or more resources that he or she 

45 manages and wants to distribute. At 833, the user selects 
users to distribute resources to. 

4. Managing Resources 

The system of the present invention provides tools that let 
the user print resource schedules and modify or delete 

50 resources from his or her system. The user can view and 
print the schedule of any resource that he or she manages. To 
view a resource's schedule, the user chooses 
Internet|Resources|View. In response-trie system displays 
Viewing Resources dialog 840, illustrated in FIG. 8E. From 

55 pulldown list 841, the user can select a particular resource to 
view and then click to print the schedule for the resource in 
weekly or monthly view. 

To modify a resource (i.e., change the properties of a 
resource), the user chooses Intemet|Resouxces|Modify from 

60 the menu. This opens a Modify Resource dialog box, which 
is similar to the Add Resource dialog box except that the 
user cannot modify the resource name. To remove a 
resource, the user chooses Internet|Resources|Remove, 
selects a resource from a displayed list, and clicks 

65 "Remove." 

If the user modifies or removes a resource that he or she 
does not manage, the user is affecting the local resource file 
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only. The user might want to delete a resource that he or she 
never uses, or might want to change a resource's description 
or owner information as displayed on his or her system. 
Since these changes affect the user's local system only, they 
do not affect others who also reserve that resource. If the 
user is the owner of the resource, deleting it has wider 
impact By deleting that resource, the user removes the 
resource's calendar, making it impossible for anyone to 
schedule that resource. If the user simply wants to stop 
managing the resource, he or she should "transfer" the 
resource. 

Transferring a resource is the act of assigning a resource 
the user owns to another manager. This is done by choosing 
Internet|Resources|Transfer from the menu. In response, the 
system displays a Transfer Resources dialog 850, illustrated 
in FIG. 8F. Here, the user selects the resource from resource 
list 851 and then clicks Transfer button 853. The system now 
displays a second Transfer Resources dialog 860, shown in 
FIG. 8G, for entering information about the new resource 
manager. Transfer is completed by clicking Transfer button 
861. 

Internal Operation 

A. Overview of Architecture and Basic Operation 

FIG. 9 is a block diagram providing an overview of the 
internal architecture of a group scheduling system 900 
constructed in accordance with the present invention. The 
group scheduling system 900 includes a main module 910 
comprising a user interface 911, a composer 912, a parser/ 
interpreter 913, an e-mail send/receive interface 914, a 
calender interface 915, and an Activities view module 916. 
Hie user interface module 911 supports entering, editing, 
and deleting of group scheduling information. The composer 
912 is employed for actually composing a group scheduling 
message. The message itself, when it is received by another 
SK client, is parsed and interpreted by the parser/interpreter 
913. The e-mail module 914 supports the sending and 
receiving of e-mail messages and documents, using com- 
mercial available e-mail providers. The calendar interface 
915 allows the main module or engine 910 to communicate 
with a separate calendar module 920. The Activities view 
module 916 supports the previously-demonstrated user ses- 
sions in Activities View mode of operation. 

General operation of the system can be divided into two 
tasks: sending an event and receiving an event message. The 
general process of sending an event is illustrated by Send 
Event Method 1000, shown in FIG. 10. The process begins 
with the user entering event information in the user 45 
interface, as indicated by step 1001. The composer module, 
acting on the user information, proceeds to compose the 
event scheduling message, at step 1002. At the point of 
composing a message, the system provides a variety of 
different message types, each corresponding to a particular 
state a meeting is at. Once a message has been composed, it 
can be inserted into the calendar, as shown by step 1003. 
Thereafter,, the system schediUes me,messa^ to.be.sent via 
the e-mail transport layer, as indicated by "e-mail delivery" 
step 1004. Once the message has been sent, the Send Event 
Method 1000 is done. 

The general process of receiving messages is illustrated 
by Receive Event Method 1100, illustrated in FIG. 11. At the 
outset, the process spawns a separate thread to receive an 
event message, at step 1101. As shown by step 1102, at a 
predetermined interval a "flash" session is initiated. During 
the flash session, the system polls the user's in-box, for 
identifying incoming scheduling messages (i.e., those hav- 
ing the signature <ISK>). 

The incoming scheduling messages are parsed by the 
parser (913), as shown at step 1103. The parser extracts 
scheduling information from the messages, storing it in an 
internal representation suitable for use by other modules of 



the system. The parser identifies, for instance, the <ISK> 
identifier, date and time information, message-type infor- 
mation (e.g., Schedule, Reschedule, Cancel, and so forth), 
and the like. The parsed information is, in turn, passed to a 
general message handler at step 1104. In response, the 
message handler triggers one of several actions, as indicated 
by step 1105, by invoking more-specific handlers—ones 
which perform the requested action. Actions include, for 
example, Schedule New 1105a, Reschedule 1105 B, Cancel 
1105c, Minutes of Meeting llOSd, Resource Reservation 
1105e, and the like. At step 1106, the parsed information is 
stored in the group scheduling database (950). From here, 
the information will also be employed, at step 1107, to 
update the calendar and/or a resource manager, as needed. 
Once updating is complete, the method is done. 

B. Core Data Structures 

1. Group Item and Group Attachment 

Before describing the internal methods of operation in 
further detail, it is first helpful to examine internal data 
structures which support operation of those methods. A 
group scheduling item is represented internally in the system 
by a "Group Item" data structure, GROUP_JTEM. In an 
exemplary embodiment, this structure may be constructed as 
follows (using the C/C++ programming language, for 
instance). 
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typedef struct 
{ 

DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
HANDLE 



dwEventlDl; 
dwEventID2; 
dwFro mDaieTunc; 
dwTbDateTlme; 
dwOldFiomDatcTlme; 
dwOicfr^DateTLme; 

dwSendRecerve; 
hTfcxt; 

HGLOBAL hRetiptent; 
DWORD IfData; 
LPGROUP_ATTACHMENT Ip Attach; 
// READ_JN_MAIN; READ_JN^TTACH; FTMPFTLE; 



DWORD 


wFIags; 


DWORD 




short 


nTexta; 


short 


nRectpients; 


short 


nPageHour; 


short 


nPagcMin; 


BYTE 


bTypes; 


BYTE 


bTimeZbne; 


BYTE 


bLead; 


BYTE 


bLeadUnit; 


}GROUP_JTEM; // total 64 bytes 


typedef GROUP_ITEM * LPGROUP_ITEM; 



As shown, the GROUP_JTEM data structure includes 
two event IDs: dwEventlDl and dwEventID2. Together, 
these comprise a 64-bit (i.e., two double words) identifier for 
each scheduling group item. This ID is employed among the 
various clients for uniquely identifying a ; rjaiticular-group<; 
scheduling item. Next, the data structure stores "from" and 
"to" date and time information in crwFromDateTime and 
dwToDateTime data members, respectively. Additionally, 
the particular item might comprise a "reschedule" item and, 
therefore, need to store the original ("old") date and time. 
This information is stored in dwOldFromDateTime and 
dwOldToDateUme data members. The dwSendRecieve data 
member also stores date and time information; it is 
employed as a time stamp indicating when a group item is 
sent or received. 

Following the date/time data members are two handles: 
hText and hRecipient. The hText data member is a handle to 
a text buffer for the subject line (e.g., 256-cbaracter string). 
The hRecipient data member, on the other hand, is a handle 
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pointing to a recipient block — a memory block storing N 
number of recipients. The lfData member serves as a pointer 
to the detailed data — that is, the data which follows the 
subject line. 

This is followed by another pointer, IpAttach, which 
points to a group attachment data structure. The group 
attachment information is, therefore, nested within (via a 
pointer) each GROUP_JTEM record. In an exemplary 
embodiment, a "Group Attachment" data structure, 
GROUP ^ATTACHMENT, may be constructed as follows. 



♦define ARRAY __LEN 
typcdef struct 
{ 



63 



WORD 



wFlags; 



// IS_MEETINGNOTE_FTLE 
// if oo then meeting note saved in file 

// REM! ND ER SENT 

nAQachSize; 

wReserved; 
IpAttachFUe; 

hRegarding; 
nRegardingB> 
tpMeetingNote; 
nMeetingNotes; 
szLocation( ARRAY _LEN+1); 
szCityt ARRAY_XEN+1 fc 
} GROUP^ATTACHMENT; // 156 bytes; 
typcdef G ROU P_ATTACHM ENT * LPGROUP_ATTACHMENT; 

As shown, the data structure includes as its first member 
nAttachSize, an integer storing a size for the attached file. 
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short 
DWORD 
LPSTR 
HG LORAL 
UINT 
LPSTR 
UINT 
char 
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This is followed by wReserve which comprises a double 
word (DWORD) currently not used The lpAttachFile data 
member stores a pointer to a text string comprising the name 
of the attach file (which itself is stored on disk). 

The next data member, hRegarding, is a handle pointing 
to a "regarding" structure which comprises the message 
body — that is, what the event is in "regards" to. This is 
followed by an integer data member, nRegardings, which 
stores a size for the regarding block which is being pointed 
to by the hRegarding handle. The IpMeetingNote data 
member is a pointer to a text block comprising a user- 
supplied meeting note text string. The size of this po in ted-to 
data structure is stored by nMeetingNotes. Finally, the 
location (e.g., particular conference room) and city where 
the meeting or event is to occur are stored by szLocation and 
szCity character strings, respectively. 

Returning to description of GROUP_ITEM data 
member, the next data member in the GROUP_JTEM data 
structure is a double word, wFlags, storing a set of flags. The 
flags indicate various information for the group item and 
group appointment (described below), including, for 
example, whether the event is Canceled, Rescheduled, or 
Deleted. In an exemplary embodiment, the following flags 
are defined. 



// flags for GROUP_APPOrNTMENT i 

#define READ__IN_MAIN 

♦define READ_IN_^ATTACH 
// tticfine FTMPFILE 

♦define HAS_MEETTNG_NOTE 

#define EVENT_CANCELED 

♦define EVENT—RESCHEDULED 
// ♦define EVENT_DELETED 

♦define SCHEDULED_EVENT 

♦define SEND_REMINDER 

Adeline REMINDER_SENT 

♦define SEND_LATER 

♦define NO_JlEPLY_ - NEEDED 

♦define RECErVED_EVENT 

♦define EVENT_JVCCEPTED 

♦define EVENT _DECUNED 

♦define UNREAD_EVENT 

♦define EVENT_FORWARDED 

#dcfinc SET_^ALARM 
only 
#define 
only 
♦define 
only 
Me fine 
♦define 



STAMP_TO_CARD 
ATTACH_JrfY_CALENDAR 



RESOURCE_EVENT 
FREETTME_EVENT 
♦define PERSONAL_EVENT 
♦define <X)Nr4DENTlAL_EVENT 
♦define PAGE_ME 
♦define UNCONFIRMED_EVENT 
♦define COMPLETED_EVENT 

♦define UNBOOKED_EVENT 

♦define EVENT_RESCHEDULE_REQUIRED 0x20000000 // receiver side 
// ♦define 0x40000000 

♦define EVENT_RECEIVE_EORWARD 0x80000000 // the second recipient 



d GROUP_rrEM.wFlag» 

0x00000001 //both 
0x00000002 //both 

0x0004 //both 
0x00000008 //both 
0x00000010 //both 

0x00000020 //both dwOldDateTune good 

0x00000040 //both 
0x00000080 // scheduler side 
0x00000100 // scheduler side 
0x00000200 // scheduler aide 
0x00000400 // scheduler side 
0x00000800 // scheduler side 
0x00001000 // receiver side 
0x00002000 // receiver side 
0x00004000 // receiver side 
0x00008000 // receiver side 
0x00010000 // receiver side 
0x00020000 // for GROUP_APPOINTMENT 

0x00040000 // for GROUP ^APPOINTMENT 

0x00080000 // for G ROUP_^APPOINTMENT 

.. ^. ..0x00100000*^- -^-i . >. .*:-..«... • 
0x00200000 
0x00800000 
0x01000000 
0x02000000 
0x04000000 
0x08000000 
0x10000000 



The flags can be combined (i.e., bitwise "or" operation), for 
65 storing in a single double word. 

The GROUP_ITEM data structure stores a second set of 
flags in another double word data member, wFlags2. In an 
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exemplary embodiment, these additional flags are defined as 
follows. 



// additional flag? 

#define EVENT_QUEUE_ITEM 0x00000001 

#dcfine EVENT_NEW_JTEM 0x00000002 

#define EVENT_jlECEIVE_RESCHEDULE 0x00000004 

#dcfinc EVENT_RJECETVE_CANCEL 0x00000008 

tfdefine EVENT_JlECEtVE__REMINDER 0x00000010 // receiver side 

#definc UNREAD_MEETING_NOTE 0x00000020 

#define EVENT__RECETVE_REPLY 0x00000040 



Following the flags, the nText data member stores a byte 
count corresponding to the size of the block pointed to by the 
hText handle (described above). The nRecipients data mem- 
ber stores a count for "the number of recipients; in an 
exemplary embodiment, up to 32,000 recipients are sup- 
ported. The next two data members, n Page Hour and 
nPageMin, specify a time to page the user; this corresponds 
to the "page me" reminder feature previously described (for 
the Scheduling Wizard, in FIG. 5H). In an exemplary 
embodiment, the page time is specified as a time interval in 
advance of the event or meeting, such as "three hours 
before** the meeting. This serves to remind the user so that 
he or she will not forget a meeting which he or she 
scheduled. 

The next data member, bTypes, stores a value describing 
the item. In an exemplary embodiment, the following types 
are defined. 



// values for bTypes in GROUP_JTEM and GROUP_APPOINTMENT 



Me fine 


SCHEDULE_JTEM 


1 


#define 


BROADCAST_ITEM 


2 


#define 


RESCHEDULE—ITEM 


3 


#define 


REMINDER^JTEM 


4 


#define 


FREE_TIME_rTEM 


5 


ftdefine 


CANCEL_ITEM 


7 


ftdefine 


REPLY_JTEM 


8 


^define 


MINUTES_JTEM 


9 


#define 


EVENT_J\CCEPT_rrEM 


10 


Adeline 


EVENT_DECLINE_rrEM 


11 


#define 


EVENT_FORWARD_REPLY_rrEM 


12 


#deflse 


EVENT_FORWARD_SOIEDULE_rrEM 


13 


#define 


EVTW_JlESCHEIXn^_REQUEST_JTEM 


14 


#dcfine 


TRANSFER_SEND_ITEM 


15 


*kfine 


TRANSFER_AOCEPT_|TEM 


16 


#define 


TRANSFER__DECLINE_JTEM 


17 


#define 


DISTRD3UTE_JTEM 


18 


#define 


BOOK^_SCHEDULE_ITEM 


19 


#define 


BOOie_RESCHEDULE_JTEM 


20 


#dcfinc 


BOOK— CANCEL_JTEM 


21 


#define 


BOOK^CCEPT_JTEM 


22 


#define 


BOOKJ>ECLINE_rrEM 


23 
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As shown, the biypes data' member can identify the item as 
a "Schedule" item, a "Broadcast** item, a "Reschedule** item, 
a "Reminder** item, a "Reply** item, a "Minutes" item, or the 
like. 

The bTimeZone data member stores an identifier uniquely 
identifying the time zone (e.g., Pacific Standard Time) that 
the dates are relative to. In this manner, the recipient user's 
system can automatically convert the times, if desired, to 
those relative to the time zone for that recipient. In a 
preferred environment, each appointment has its own time 
zone — typically, the time zone in which the item was 
originally scheduled. The recipient systems convert this 
information to and from their own relative time zones, as 
needed. 
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Finally, the bLead and bLeadUnit data members store 
15 information describing a "lead** time or reminder. This 
information allows the system to send reminders to all 
participants at a specified interval (e.g., three days). 
2. Each Recipient 
20 Bach recipient involved with a group scheduling message 
is represented internally by a recipient data structure: 
EACH_RECIPIENT. In an exemplary embodiment, the 
data structure may be constructed as follows. 
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typedef struct 
{ 

char 
char 
long 
long 

DWORD 



szName[32]; 
szEmaiI[64]; 

in>, 

UD2; 
wFlags; 



// type of e-mail, Has free time, 
// sender or not, tile flag 
DWORD wStatus; // status flags, message or free time saved, 
long IfD&ta; // point to tree time file and ShortMsg mail 

LPRECIPIENT_JDAIA tpAttach; 

// HGLOBAL hAttach; // a RECJPTENT_DATA structure 
} EACH_RECD?[ENT, // 114 
typedef EACH__RECIPTENT • LPEAOi_REOTIENT, 



As shown, the first data member, szName, stores a text string 
40 comprising the recipient's name (e.g., "John Smith** ). This 
is followed by another text string, szEmail, which stores the 
e-mail address for the recipient. Following the recipient 
name and e-mail address are two identifier data members: 
1ID and 1ID2. These IDs are used in combination to uniquely 
describe a particular recipient. 

Following the identifiers is a double word data member, 
wFlags, storing recipient flags. The recipient flags indicate, 
for instance, whether the recipient has free time, whether the 
50 recipient accepts or declines, and so forth. In an exemplary 
embodiment, the status flags may be defined as follows. 



// type of e-mails, tax, or page in EACH_RECIPIENT structure 


^define TYPE_E-mail AOL 


0x0001 


^define TYPEJ-mail_COMPUSEKVE 


0x0002 


^define TYPE_E-mni]_FXCHANGE 


0x0004 


We fine TYPE J-mafl_JNTERNET 


0x0008 


tfdefine TYPE__FAX 


0x0010 


^define TYPEJPAGE 


0x0020 


*Uefine TYPE_PHONE 


0x0040 


//define TYPE_MAHING_LIST 


0x0080 


// type of recipient 




^define TYPE_PAKTICIPANT 


0x0100 


flttefine TYPE__CC 


0x0200 


ftdefinc TYPE_ROOM 


0x0400 


ttiefinc TYPE_JEQUD?MENT 


0x0800 


// also, TYPE_OTHERS defined below 




// misc. flags 
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Mefinc IS_SENDER 0x1000 

#define IS_SELF 0x2000 

#dcfinc HAS_REaPIENT_DATA 0x4000 

#define READ_IN_REC[PIENT _DATA 0x8000 

#dcfine F__LIST_DIKTY 0x00010000 

#define TYPE_OTHERS 0x00020000 

#dcfinc CARD_JD_SET 0x00040000 

^define TYPE_PAGE_ME 0x00080000 

#definc RECIPlENT_RECErVED _F0KWARD 0x00100000 

#dcfinc REdPIENT_SENT_FORWARD 0x00200000 
// Recipient status Bags 

// #define REdPIENT_STATUS 0x0001 

#define REdPIENT_FREE_TIME 0x0002 

REC3PTEI^rr_FORWARD 0x0004 

REaPIENT__E-maiL^ADDRESS 0x0008 

RECIPIENT_NAME 0x0010 

REC3PIENT_CARD_JD 0x0020 

REC1PIENT_31AIL_STATUS 0x0040 

RECIPIENT_^ACCEPT 0x0080 

RE(HP[ENT_DECLINE 0x0100 

RECIPIENT __R£SCHEDULE_RECHiIRED 0x0200 

RECIPIEW__RESOURCE_OONF1JCT 0x0400 
RECIPIENT_RESOURCE_TRANSFERRED 0x0800 

REaPIENT_RESOU RCE_NOT_POUND 0x1000 

RECIPIENT__RESOURCE_CANCELED 0x2000 
// flags for resource events (from 0x00010000 to 0x80000000) 

#define RECEIVE_DCSTRIBUTE_RESOURCE 0x00010000 

RECEIVE_BOOK_RESOURCE 0x00020000 

SENT_BOOK_RESOURCE 0x00040000 25 

REC£IVE_TRANSFER_RESOURCE 0x00080000 

SENT_TRANSFER__RESOURCE 0x00100000 

TRANSFERS-SUCCESSFUL 0x00200000 



tide fine 
#define 
#defioe 
#define 
#define 
Odefine 
#define 
#definc 
Mefinc 
#define 
#definc 
Mefinc 



#define 
^define 
^define 
Mefinc 
#define 
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invitation, or whether the recipient required rescheduling. 
Additionally, at this point, flag information is stored for 
resources, such as information indicating that the resource is 
not found, that the resource has been transferred, that the 
resource has been canceled, or that a conflict for the resource 
exists. 

Returning to the description of the EACH_RECIPIENT 
data structure, the next data member, IfData, is a pointer to 
a data block for the recipient; the data block stores free time 
information and a short message for the recipient. Finally, 
the EACH_RECTPIENT date structure stores a pointer, 
lpAttach, which points to a RECIPI ENT_D ATA structure. 
This structure will now be described. 

3. Recipient Data 

The RECI PIENT_D ATA structure stores free time and 
rescheduling information for a particular recipient. In an 
exemplary embodiment, the data structure may be defined as 
follows. 
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As shown, the information indicates the type of 30 
delivery — e-mails, fax, or page — desired for a particular 
recipient, thereby supporting methods for communicating 
with all types of recipients, other than just e-mail. For e-mail 
types, support is provided for multiple providers, including, 
for instance, America On-line (AOL), CompuServe, 35 
Microsoft Exchange, and the Internet For a recipient to be 
contacted via phone (i.e., type is TYPE_J>HONE), the 
system adds an item to the user's "call list" — that is, a list 
of calls the user is to make (as shown at 440, in FIG. 4). A 
delivery type of "mailing list" indicates that the system is to 
process multiple recipients according to a mailing list. 

The flags also indicate a recipient type. A recipient can be, 
for instance, a "participant" (i.e., type is TYPE_ 
PARTICIPANT) — someone who is required to reply. A 
"CC recipient (i.e., type is TYPE_CQ, on the other hand, 
is not required to reply. Other types of "recipients" include 
"room," such as a conference room, and "equipment," such 
as a projector. Finally, a recipient can be simply set to 
"others" for indicating that the recipient is other than that 
above. 

As a. group scheduling item is associated with a list of 
recipients, it is helpful to further characterize recipients. In 
this regard, a "sender" flag (type is IS„SENDER) is 
employed for indicating that the recipient is actually the 
sender. A "self" flag (type is IS_SELF), on the other hand, 
indicates that the recipient is "self" — that is, the same 
individual as the user. Other recipient-type information 
serves to further characterize the recipient. For instance, the 
"page me" flag indicates that this recipient is to be paged. A 
"sent forward" flag, on the other hand, indicates that this 
recipient has delegated the item to another user. 

Finally, the recipient flags store status information for 
each recipient. Status includes, for instance, information 
indicating whether the recipient accepted or declined the 
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typedef struct 
{ 

DWORD dwFUgs; // Reserved - not used 
long IStart; 
long lEnd; 

DWORD dwRcachcduIcStait{3i 



DWORD dwRescheduleEndpt 



reschedule request start 
date/ time 

reschedule request end 
date/tune 



65 



LPSTR tpMsg; 
LPSTR IpFreeTime; 
void • IpNezt; 
} RECIPIENT _JDAXA; 

typedef RECD? IENT_DArA * LPRECIPDZNT_DArA; 



As shown, the first data member, dwFIags, comprises a 
double word data member storing flag or status information; 
it is currently not used. The next two data members, IStart 
and lEnd, indicate a free time range (e.g., next 30 days). 
Then, the next two data members, dwRescheduleStart and 
dwRescheduleEnd, store information specifying a resched- 
ule request start date/time and reschedule request end date/ 
time, respectively. As each of these data members comprises 
an array of size three, these data members actually indicate 
three rescheduling alternatives. 

The next data member, lpMsg, comprises a pointer to a 
text string storing a message associated with the reschedule 
request (e.g., "Sorry, I am in Chicago next week; please 
reschedule."). This is followed by a pointer, IpFreeTime, 
which points to a block describing the free time for the 
recipient (i.e., information employed for displaying a Free 
Time report for this recipient). Finally, the data structure 
includes a "next" pointer, for pointing to a subsequent 
RECIPIENT __DAXA structure. 

Each RECIPIENT ^ATAstructure, when saved to file, is 
associated with a header: RECIPIENT _J) ATA^_HEADER . 
In an exemplary embodiment, the header may be con- 
structed as follows. 



typedef struct 
{ 

DWORD dwFIags; 
UINT nMsgs; 
UTNT nFreeTimes; 
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long IStort; 

long IRnd; 

DWORD dwReschedutcStart[3t i 

DWORD dwRescheduleEndpt } 

} REOPIENT_J)ArA_HEADER; 
typedef RECtPIENT_DAL^_HEADER 
LPRECIPIENT__DArA_HEADER; 



reschedule request 
start date/time 
reschedule request 
end date/ time 



The header includes data members the same as or similar to 
those described for RECIPIENT_DArA. Additionally, the 
header stores a number of messages, nMsgs, and a number 
of free times, nFreelunes. 

Also stored is a footer: RECIPIENT _JWA^JFOOTER. 
This may be constructed as follows. 



typcdef struct 
{ 

DWORD IfData; // -1 if no next item. 
} REQPIENT__DATAJOOTER; 
typcdef RECn > TENT_X)ArA_JffiADER * 
LPREOPIENT-DATA^HEADER; 
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The footer simply comprises a single data member, IfData, 
which serves to indicate whether a "next" recipient data item 
exists (in a chain of recipient data records). 
4. Group Appointment 

At run time, a memory block or buffer is allocated for 
storing context information. This buffer is organized into a 
GROUP_>\PPOINTMENT structure, for describing a par- 
ticular group appointment. In an exemplary embodiment, 
this data structure may be constructed as follows. 
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typcdef stiuct 






DWORD 


dwEvenlTDl; 




DWORD 


dwEventID2; 




DWORD 


dwFro mDateTtmc; 




DWORD 


dwlbDateTune; 




DWORD 


dwOUFromDateTime; 




DWORD 


dwOldToDatcTimc; 




DWORD 


dwRescbedulcStartp]; 




DWORD 


dwReschednleEndpt 




DWORD 


dwSendReceive; 




HANDLE 


hText; 




HANDLE 


hRegarding; 




HANDLE 


hRecipient; 




LPSTR 


[pMeetingNote; // meetii 


ig note file name 


LPSTR 


IpShortMsg; 




LPSTR 


IpDelegaleMsg; 




LPSTR 


lpFreeTune; 




int 


nls Delegate; 




int 


nls Resource; 




HANDLE 


hForward; 




WORD 


□Texts; 




WORD 


oRegardings; 




WORD 


nRecipientg; 




DWORD 


wFlagm // READ_IN 




DWORD 


wFlags2; 
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short nPagcHour; 

short nPagcMin; 

BYTE bLeadHour, 

BYTE bLeadMin; 

BYTE bReminderLead; 

BYTE bRemwderUnit; 

BYTE bTimeZonc; 

BYTE bTypes; 

int nTonc; 

DWORD IfData; ff 42 

int nResocrceStatus; 

char 8zResourccName(64t 

char 8zLccatton[64( 

char szCity(64i 

char szSenderName{32l 

char szSenderE-maQ[64£ 

int oSenderE- maflType; 

char szAttachTOe[PATHMAX+4i 

EACH_REaPIENT Page Me; 

HGLOBAL hPlacelist; 

int cPkuxLists; 

// LPSTR IpTZ; 

// int nTZs; 
} GROUP_APPOINTMENT, // total 136 bytes 
typcdef GROUP_APPOrNTMENT * LPGROUP ^APPOINTMENT; 



This temporary, in -memory data structure (i.e., it is not 
saved to disk) largely comprises data members taken from 
the previously-described data structures. Additionally, 
however, the data structure stores information further 
describing any delegation. For instance, the IpDelegateMsg 
data member points to a delegate message text string. This 
allows one recipient to send a message to a delegated-to 
recipient, yet not have that text string message returned to 
the originator of the invitation. Additionally, delegation is 
35 supported by the szSenderName and szSenderE-mail data 
members. This information indicates who the delegated to 
recipient should respond to — that is, the originator of the 
invitation. 

Group Scheduling Methodology 
1. Schedule Group Event 

With an understanding of the internal day structures 
employed, methods of operation may now be examined in 
further detail. Group scheduling begins with a request to 
schedule a group event. This request results from user input 
occurring at the user interface, as illustrated at step 1001 in 
FIG. 10. Actual operation of the user interface itself such as 
processing menu selections and user input at edit fields, may 
5q be done in a conventional manner using standard windows 
graphical user interface (GUI) methodology. 

Once the user input has culminated in a request to 
schedule a group event, the request is processed by the group 
scheduling module or engine 910 (of FIG. 9). This module 
internally invokes a Schedule_Group_Event method. In an 
exemplary embodiment, the Schedule__Group_Event han- 
dler or method may be constructed as follows (again, using 
the C/C++ programming language). 
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2: Schedule a following type of group events: 
3: - Normal group event (reply required) 

4: - Broadcast group event (do reply needed) 

5: - Reminder 

6: - Reschedule 
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Free time 
Cancel meeting. 



10: int Schedule_Group_Event (LPGROUP_APPO[NTMENT IpNew, 

11: int nAddTbLtst, int nAddTb Appointment, int nFromCaJcndar, 

12: LPSTR IplnBuf, int nlnStzc) 

13: { 

14: GROUP.JTEM Groapltem; 

15: LPSTR bpMessagc - lpInBaf; 

16: int nlndez - -1; 

17: 

18: if (UpMessage) 

19: { 

20: lpMcssage - AllocLockBufiferPtr (NOTETEXFSIZE • 3); 

21: nlnSize - NOTETEXTSIZE • 3; 

22: } 
23: 

24: if (tlpMessage) 

25: return FALSE; 
26: 

27: nstartGroupEvcnt - TRUE; 
28: 

29: // Save to appointment List in Olcndar module. 

30: if (IpNew — >hRcripient && rpNcw — >nRecipients) 

31: { 

32: // get send and receive time. 

33: if (IpNew— >bTypcs — SCHEDU1JE_ITEM || IpNew— >bTypes 

34: — BROADCAST_rTEM | | rpNew-^Types 

35: — RESCHEDULE_JTEM | | IpNew— >bTypes — CANCEL_JTEM) 

36: time (&(lpNcw — xrwScndRcccivHe)); 

37: 

38: // - add call items to call list. 

39: if (IpNew— >bTypes — SCHEDULE_TTEM 

40: 1 1 IpNew— >bTypes — BROADCAST_JTEM) 

41: Inseit_Cslls_Calendar (IpNew); 

42: 

43: // - add send letter to todo lisL 

44: if (IpNew— >bTypes - SCHEDULE_JTEM 

45: 1 1 IpNew— >bTypes — BROADCAST _JTEM) 

46: Insert_Todo8_Calendar (IpNew); 

47: 

48: // add/edit/delete calendar item 

49: if (tnFromCalendar) 

50: { 

51 : if (CpNew— >bTypcs — SCHEDULE_JTEM 

52: | | IpNew— sbTypes — BROADCAST__rrEM) 

53: && nAddToAppointment) 

54: { 

55: if (JQpNew— >wFlags & UNBOOKED _JEVENT)) 

56: AddNewAppointment_J«romGROUP (IpNcw); 

57: // AddNewGroupAppointment (IpNew); 

58: } 

59: else if OpNcw-obTypcs — RESCHEDULEJTEM) 

60: { 

61 : // #### Reschedule Appointment 

62: ChangcExistAppointinent__FromGROUP (IpNcw); 

63: } 

64: else if (IpNcw— >bTypes — CANCEL_rTEM) 

65: { 

66: // #### delete appointment 

67: I>leteExistAppointmeni_FromGROUP (IpNew); 

68: } 

69: . } 
70:' 

71: // add item to GROUP event data base. 

72: if (nAddToList) 

73: { 

74: ResolveAllMailingLists (IpNcw); 

75: if(tGROUP^AppointmenL_To_GROUP _Jtcm(lpNew, AGroupItem)) 

76: { 

77: UnlockFieeBuSerPtr (lpMcssage); 

78: return FALSE; 

79: } 

80: GroopItemwFlags =- READ_tN_MAIN | READ_IN_ATTACH; 

81: GroupItemwFUgs =- SCHEDULED _JiVENT, 

82: Group[tem.wFlags2 =- EVENT_QUEUE_JTEM; 

83: if (tlsBroadcaslType (&GroupItem)) 

84: { 

85: ResoWcAllExchangeMailingLists (AGioupltem); 

86: } 
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87: 

88: ScanForSel£_SetAecept (ftGroupttcm); 

89: // actual call to add item to GROUP event database 

90: nlndex 

91: - AddOrjeGroupItcm ( NULL, ftGroupIrem, 

92: SCHEDULED__HVENT, 

93: Get CurrenL^SortFlag ( )); 

94: // . . . DEBUG 

95: } 

96: // empty else case . . . 

97: // Now COMPOSE MESSAGE 

98: if (!(lpNew— >wFlags & SEND_LATER)) 

99: { 

100: if (IpNew— >bTypes — SCHEDULE_JTEM) 

101: { 

102: ComposeScheduleMessage (IpNew, 

103: MSG_SCHEDULE, IpMessage, nlnSize); 

104: } 

105: else if (IpNew— >bTypes — BROADCAST _JTEM) 

106: { 

107: CbmposeScheduleMessagc (IpNew, MSG ^BROADCAST, 

108: IpMessage, olnSize); 

109: } 

110: else if (IpNew— >bTypes — REMINDER_ITKM) 

111: { 

112: ComposeScheduleMessage (IpNew, MSG_REMINDER, 

113: IpMessage, nlnSize); 

114: blsReminderMsg - TRUE; 

115: } 

116: else if (IpNew— >bTypes — RESCHEDULE ITEM) 

117: { 

118: ComposeScheduleMessage (IpNew, MSG__RESCHEDULE > 

119: IpMessage, nlnSize); 

120: } 

121: else if (IpNew— >bTypes — CANCEL_JTEM) 

122: { 

123: ComposcOmcelMcssage (IpNew, IpMessage, nlnSizcX 

124: } 

125: 

126: // - send email; 

127: Seod_AOL_JSmail (IpNew, IpMessage); 

128: Send_CompuServe_Email (IpNew, IpMessage, FALSE); 

129: Send_Exchange__Email (IpNew, IpMessage, FALSE); 

130: Send_Internet_Email (IpNew, IpMessage, FALSE); 

131: 

132: 

133: // - send fax; 

134: Send_Group_Fax (IpNew, IpMessage, FALSE); 
135: 

136: if (OpNew— >bTypes — SCHEDULE_ITEM) 1 1 

137: (lpNew-^>bTvpea — BROADCAST_ITEM) 1 1 

138: (IpNew— >bTypes — RESCHEDULE_JTEM) 1 1 

139: (IpNew— >bTypcs — CANCEL_JTEM)) 

140: { 

141: int nLen - lstden (IpMessage); 
142: 

143: Loadstring (hCmrdfilelnstance, 

144: IDS_THIS_IS_RESOURCE, IpMessage + nLen, BUF_LEN>, 
145: 

146: Send_CompuServe_Email (IpNew, IpMessage, TRUE); 

147: Send^Excbange Email (IpNew, IpMessage, TRUE); 

148: Send_Inte rr*t_Email (IpNew, IpMessage, TRUE); 

149: Send_Group_Fax (IpNew, IpMessage, TRUE); 

150: } 
151: 

152: // - send page; 

153: Send_Group_Page (IpNew, FALSE); 

154: blsReminderMsg - FALSE; 

155: } 

1 56: fcchcduledDirty - TRUE; 

157: } 

158: else 

159: { 

160: AddNewAppointment FromGROUP (IpNew); 

161: } 

162: if(IlplnBuf) 

163: UnlockFreeBuScrPtr (IpMessage); 
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164: nStartGroupEvent - FALSE; 
165: 

166: return TRUE; 
167: } 

(line d timbers added above to aid in the following description) 



This method is invoked after the user has completed UI 
data entry. It serves to schedule one of the following types 
of group events: Normal group event (reply required), 
Broadcast group event (no reply required), Reminder, 
Reschedule, Free Time, or Cancel meeting. 

The parameters required for the method are set forth at 
lines 10-12. The first parameter, IpNew, references a new 
group appointment data structure (described above). The 
second parameter, nAddToList, indicates that this group 
event should be added to the group scheduling database. The 
third parameter, oAddTo Appointment, indicates whether the 
event should be added to the user's appointments (listed in 
the user's calendar). The fourth parameter, nFromCalendar 
indicates that this request is originating from the user's 
calendar, for example, as a result of a drag-and-drop event 
occurring in the calendar. The first two parameters, lpnBuff 
and nSize, characterize a passed-in memory buffer; the 
memory buffer is typically used for storing message strings. 
At lines 14-16, the method initializes local (stack) variables. 
At lines 18-25, the method attempts to allocate a memory 
buffer for storing a message. If a buffer cannot be success- 
fully allocated, the method returns "false" at line 25. At line 
27, the method initializes a global variable, 
nStartGroupEvent, to the value of "true." 

Starting at line 29, the method will undertake to save the 
group event to the appointment list in the calendar module. 
This occurs as follows. At line 30, the method tests whether 
there are recipients — that is, whether this is a "group" 
appointment Otherwise (i.e., the condition at line 30 is 
(false), the event is instead a "local" appointment Between 
lines 32 and 69, the method tests group appointment flags for 
determining its course of action. At lines 32-36, for instance, 
if the event is a "Schedule" item, a "Broadcast" item, a 
"Reschedule" item, or a "Cancel" item, the previously- 
described dwSendRecieve time stamp is updated at line 36. 
At lines 38-41, the method adds a Schedule or Broadcast 
item to the user's call list In a similar manner, at lines 
43-46, the method adds a Schedule or Broadcast item to the 
user's "to do" list. The "insert calendar" call serves to call 
into the calendar module 920 (of FIG. 9). 

At lines 48-49, the method tests whether the event request 
originated from the calendar. If not, then the method must 
add the event to the appointment list, if the requested event 
is a Schedule or Broadcast item. Specifically, the method 
invokes an AddNe wAppoin tment_JF rom G RO UP subrou- 
tine at line 56. Otherwise, the method tests whether the event 
is a Reschedule item (at line 59) or a Cancel item (at line 64). 
For a Reschedule item, the method changes the existing 
appointment, at line 62. For a Cancel item, on the other 
hand, the method deletes the existing appointment, at line 
67. 

At lines 71-95, the method undertakes to add the event 
item to the group scheduling (event) database 950 (of FIG. 
9). Specifically, the method tests the nAddToList parameter, 
at line 72. If this is set to "true" (i.e., greater than 0), the 
method proceeds to convert the group appointment into a 
group item, resolving all recipients on any mailing lists. The 
actual call to add the item to the database occurs at lines 
89-93, where one group item is added. 



Starting with line 97, the method will now undertake 

1° composing of the message for notifying recipients of the 
group scheduling event At line 98, the method tests a 
SEND — LATER flag, which indicates whether the schedul- 
ing message is to be sent later. If the message is not to be sent 
later (i.e., the "if" statement at line 98 evaluates to "true"), 

15 then the group scheduling event message must be composed 
now. In such a case, the method will proceed to compose and 
send a message, at lines 99-155. Steps of the method for 
composing and sending the message will be described next. 
Lines 100-124 set forth a sequence of "else if" case-like 

20 statements which switch on the item type. At line 100, for 
instance, if the item is a Schedule item, the method invokes 
the composer at lines 102-103, for composing a Schedule 
message (MSG SCHEDULE). If, instead, the item is a 
Broadcast item, tested at line 105, the method invokes the 

25 composer at lines 107-108, for composing a Broadcast 
message (MSG — BROADCAST). For a Reminder item, 
tested at line U0, the method invokes the composer at lines 

112-113, for composing a reminder message (MSG 

REMINDER). For a Reschedule item, tested at line 116, the 

30 method invokes the composer at lines 118-119, for com- 
posing a reschedule message (MSG_RESCHEDULE). 
Finally, if the item is a Cancel item, tested at line 121, the 
method invokes the composer at line 123, for composing a 
cancel message. The foregoing steps, therefore, invoke an 

35 appropriate handler in the composer 912 (of FIG. 9) for 
creating an appropriate message. The message itself is stored 
in the memory buffer pointed to by lpMessage — the memory 
buffer allocated at lines 18-25. After the task of composing 
the message is done, the method proceeds to send the 

40 message using the appropriate transport for each recipient 
At lines 126-130, the method invokes the e-mail module 
or manager for transporting the message over available 
services: America On-Line (handler invoked at line 127, 
CompuServe (handler invoked at line 128), Microsoft 

45 Exchange (handler invoked at line 129), and Internet 
(handler invoked at line 130). As shown, each handler 
invocation passes a pointer to the GROUP„ 
APPOINTMENT data structure as well as a pointer to the 
message buffer (which holds the just-created group sched- 

50 uling event message). As shown, a Boolean parameter is 
passed with the value of "false" for indicating that the 
message is not for a resource (which requires a slightly 
different format). For each 'handler invocation, the e-mail 
module will enumerate the recipients for the respective 

55 services and post group scheduling event messages accord- 
ingly. 

At lines 133-134, the method invokes a fax handler for 
sending facsimile transmissions to the recipients which are 
preferably reached via that mechanism. Faxing from the 
60 computer can be done in a conventional manner, using a 
"Fax modem" and built-in Fax support (e.g., in Microsoft 
Windows® 95, available from Microsoft Corp. of Redmond, 
Wash.). 

At lines 136-150, the method essentially repeats the 
65 foregoing steps of invoking e-mail and fax handlers, except 
that here the process is undertaken for a resource. The 
process is essentially the same except that at lines 141-144 
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the method modifies the just-created message (stored in the 
memory buffer) for adding an identifier indicating that the 
group scheduling event is for a resource. At lines 152-153, 
the method invokes a SendGroupPage handler for process- 
ing any request to page a recipient (or the user himself or 
herself). At lines 154 and 156 local cleanup is performed. 

At line 158, an "else" statement is defined. This statement 
is reached in the event that the message is to be sent later 
(i.e., the "if statement of line 98 evaluates to "false"). In 
such a case, the method simply adds a new appointment, at 
line 160. Steps are not undertaken at this point to compose 
and/or post a group scheduling event message. Finally, the 
method performs local cleanup, such as freeing the message 
buffer, at lines 162-163. After resetting the nStartGroupE- 
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calendar with the embedded calendar. The synchronization 
generic in nature, so that it can be extended to any data 
object which is capable of synchronization. 

5 b. Message Body 

Following the signature and message-type is (if required) 
a message body. Here, the system includes specific data 
items which characterize the scheduling event. The message 
10 body for Schedule and Broadcast message-types is exem- 
plary in this regard. In an exemplary environment, a mes- 
sage body for these message-types may be constructed as 
follows: 



<From Dale Timc> YY/MM/DD HHiMM 

<Ob Date Timc> :- YY/MM/DD HHiMM ^' 
<Locatioa> Place name where the meeting will be held 

<City> :» City name where the meeting will be held It is related to Time Zone. 

<Time Zone> > <Time zone name where appoint me tit time is based on> 

<Attributes> :- <Alarm> 

<EventIDl> := A unique ID for the event 

<EventID2> :- The second part of the ID. 

<Sobject> <Message textx/Subject> 

<Mcssage Content> <Regarding tcxlx/Messagc Contcnt> 

<Participanta> :>- "Name; Email address; Email Type" "Name; Email Address; 

Email Type" </Participants> 

«GC> :- "Name; Email address; Email Type" "Name; Email Address; Email Type" 
<JOC> 

<Room> : — "Name; Email address; Email Type" "Name; Email Address; Email Type" 
</Room> 

<Equipment> "Name; Email address; Email Type" "Name; PmnQ Address; Email 
Type" 

</Equipment> 



vent global flag, at line 164, the method returns "true," at As shown, the message body includes data items which 
line 166, whereupon the method is completed. 35 correspond to the previously-described internal data struc- 
2. Composing Messages ^ tures. For instance, the group scheduling event is character- 
To understand methods of the present invention for com- . , , ut . „ . u . „ , . . . . , 

. _ - . , A , .J 4 # , lzed by a "from and a to date and time, a location, a city, 

posing messages, it is helpful at the outset to examine group J , , „ . . . 

scheduling formats employed by the system for creating a Ume 7xm *> tbe ,ike * ^ event 15 ldenUfied b y 

messages. In general, messages are created using delimiters, ^ previously-described two-part event ID. The message body 
thereby, avoiding position dependency of particular in for- concludes with a list of e-mail addresses, including 
mation within a message. addresses for participants, "CC" recipients, and resources 

a. Message Formats (divided into "room'' and "equipment" subtypes). Each of 

In an exemplary ermronment^ every message includes a mese ^ items may comprise a list of e-mail addresses, 

signature and a message type, which may be constructed as ^ 

follows: The message body for a reply message, on the other hand, 

is constructed as follows. 



<Product Signature> :« <ISK> (or <5IS>) 
<Message Typo <5chcdulc\Broadaurt\Rcply\Frec Timc\ 



<Short Message> <Short text message x/Short Message> 



Reminder^chcduleXMecting Notc\CanccKRecurring\Ncw Resource 50 f Cply J^ pCS> xc <Acccpt\T>^ii*tfle^ule Requin^Sleep\ 

Resourcr\Action\3yiichiDiiizatioa> Forward\Re^)iirce\Free Timo 

________ <Forward To> :■» <Name; E-mail address; Email Typo 

^Forward To> 

As shown, the message includes tbe prevriously-described , << if R«ched^ reamred f , ; r ;/ ^ JVV 

' „ • i ™_ <From Date Time> YY/MM/DD HH:MM 

signature followed by a particular message-type. The <To Date Time> - yy/mm/dd HHiMM 

message-type itself can be any one of the following: 55 » 

Schedule, Broadcast, Reply, Free Time, Reminder, <EventiDl> > A unique ID for the event 

Reschedule, Meeting Note, Cancel, Recurring, New ^ 8< ^ d P artofthc ro 
Resource, Resource, Action, and Synchronization. Tbe 
"Action" message-type supports workflow applications. 

Here, tbe message serves as a "to do" item or task for one 60 

or more recipient users. The "Synchronization" message, on toe message body includes data items corresponding 

the other hand, serves to synchronize two or more data to the previously-described data members in the group 

objects, such as user calendars. Recall that a data object scheduling internal data structures. A reply includes, for 

characterizing a calendar (e.g., free time data object) can be instance, a reply type, such as "Accept,** "Decline," 

imbedded within a message. A Synchronization message- 65 "Reschedule required," or the like. In tbe event that tbe 

type, therefore, exchanges calendars and instructs the recipi- replying user has delegated the event, the delegated-to user's 

ent system to automatically synchronize the recipient's address is provided in the "forward to" field. If the reply 
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request rescheduling, rescheduling date and time informa- 
tion is included. For this type of message, the message also 
includes a file attachment providing further information for 
(e.g., Free Time report). Finally, the message includes the 
two-part event ID, so that the reply can be matched up with 
the original invitation. Any message provided by the reply- 
ing user is transmitted in the message field, "short message." 
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The "sleep" message-type is provided for those users who 
are on vacation. Exemplary message bodies for other mes- 
sage types are appended herewith as Appendix A. 
c. Methodology for Composing Messages 
5 In an exemplary environment, a method for composing 
scheduling event messages, ComposedScheduledMessage, 
may be constructed as follows. 



1: /••"—• .......... ... 

2: This function is called for schedule a: 

3: - Schedule meeting 

4: - Broadcast meeting 

5: - Reminder 

6: - Reschedule 

7: 

8: Meeting message format is: 

9: 

10: <Messagc Type> message type name\r\n 

11: <01d Date Time> yy/mm/dd hh:mm\r\n (if it's a reschedule message) 

12: <From Dale Time> yy/mm/dd hh:mm\r\n 

13: <To Date Time> yy/mm/dd hh:mm\r\n 

14: <Location> location aame\r\n 

15: <Tune Zone> time zone vahie\r\n 

16: <Attributes> "attribute" "attribute" . . . \r\n 

17: <EveniIDl> EvenuDl value string\r\n 

18: <EveniID2> EventID2 value string\r\n 

19: <Subject> Text body</Subject>\r\n 

20: <Message Oontent> Regarding body</Message Cbnlcnt>\r\n 

21: 

22: 

23: *** ............. *•••••••••«.•••••.•••.••••• 

24: int CompoaeScheduleMessagc (U*GROUP_^APPOINTMENT IpGroup, 

25: int nMessageType, 

26: LPSTR IpMessage, 

27: int nSize) 

28: { 

29: char szField[BUF_JLEN+lL szSpace[2L 

30: szReturn[5l szTime(BUF _LEN+lt 

31: int nlsRescbefhile - FALSE, nlsBroadCast - FALSE; 

32: LPSTR IpBuf; 

33: BYTE bTypes; 

34: 

35: szSpacefO] - • *; 

36: szSpaccfl] - 0; 

37: GetReturnNewiine (szRetum); 

38: 

39: if ((nMessageType — MSG_DISTRIBUTE_RESOURCE) 

40: 1 1 (nMessageType — MSG_TRANSFER_RESOURCE)) 

41: { 

42: LoadGenericHeaderMessage QpMessage); 

43: } 

44: else 

45: { 

46: if (nMessageType — MSG_SCHEDULE 1 1 

47: nMessageType — MSG_REMINDER 1 1 

48: nMessageType — MSG_BROADCAST | | 

49: nMessageType — MSG_RESCHEDULE) 

50: Load_ISmv4essage_Header (tpGronp, IpMessage, nSize); 

51: } 

52: 

53: 

.54:,/- .... ....... . 

55:" " ' 

56: This message was generated by Internet Sidekick. 

57: * If you have Internet Sidekick installed on your system: 

58: - Please ignore tins message and do not delete it from you inbox. 

59: - Internet Sidekick will automatically process it next time you 

60: Send/Receive messages or during the next scheduled Flash Session. 

61: 

62: * If you do not have Internet Sidekick: 

63: - You can reply to this invitation using your e-mail software. 

64: Type an X next to either Accept or Decline below, so it reads 

65: [X] Accept or [X] Decline. 

66: - You can also enter a short message as part of your reply to the 

67: initiator in the blank section between <BEGIN REPLY MESSAGE> and 

68: <END REPLY MESSAG£>. 

69: - When you reply from your E-mail product, make sure that the reply 

70: includes the whole original message body including the section 
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-continued 



below the beading. For Internet Sidekick Use Only. Also do not 
modify or delete the Subject of this e-mail message. 

- For further information on how to procure it, please visit 
Starfish Software's web site at: 

<http://wwwjtarfish3ofrwarc.com >. 



Message From: {Initiator} 
Date/Time: {Date/Time} 
Duration: {Duration} 
Time Zone: {Time Zone} 
Location: {Location} 
City/Country: {City} 

Subject: {Subject} 
Message: {Message} 



<BEGIN REPLY> 
Your Reply: 

f 1 Accept 
[] Decline 
<END REPLY> 

Reply Message: 

<BECHN REPLY MESSAGE> 

<END REPLY MESSAGE> 



The section below is for Interact Sidekick Use Only. 
Please, do not edit or delete any of the information 
below this line. 



// append <Message Typo and space 
load-String (hCaidfilelnstance, 

roS_SKWGROUP_MESSAGE_TYPE_JD, 

rpMessage+lsu-lenflpMcssage), nSize); 
lstrcat (IpMessage, szSpace); 

// append Schedule, Broadcast/ Re minder, Reschedule 

switch (nMessageType) 

{ 

case MSG_SCHEDUUE: 

LoadString QiCardfilelnstance, 

rDS_SKWGROUP_SCHEDULE, szField, BUF_LEN); 

break; 

case MSG_BROADCAST: 
LoadString (hCardfilelnstance, 

n5S_SKWGROUP_ BROADCAST, 
szField, BUF_LEN); 
nlsBroadCast - TRUE; 
break; 

case MSG__REMINDER: 

LoadString (hCardfilelnstance, 

lDS_SKWGROUP_JlEMINDER, szField, BUF _JUEN); 

break; 

case MSG_RESCHEDULE: 

LoadString (hCardfilelnst&nce, - ■ . 

D^_SKWGROUP_JlESCHEDULE, szField, BUF __LEN); 
pIsResrhrdiile - TRUE; 
break; 

case MSG_RESOURCE: 

LoadString (hOrdfilelnstance, 

IDS_SKWGROUP_RESOURCE_SCHEDULE, 

szField, BUF_LEN); 

break; 

case MSG_DlSTRlBUTE_RESOURCE: 
LoadString (hCardfilelnstance, 

lDS_SKWGROUP _JVEW ..RESOURCE, 
szField, BUF_JLEN); 

break; 

case MSG_RESOURCE_RESCHEDULE: 
LoadString (hCardfilelnstance, 

IDS_SKWGROUP_RESOURCE_JlESCHEDULE, 
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151: szFicld, BUF_LEN), 

152: break; 

153: case MSG_JlESOURCE__CANCEL: 

154: LoadString (hCanifilelnstance, 

155: IDS_SKWGROUP_RESOURCE_CANCEL > 
156: szFiekL BUF_LEN); 

157: break; 

158: } 

159: AppcrjdString (lp Message, szFicld, 

160: azRetum, NULL, NULL, NULL, nSize); 

161: 

162: if (nlsReschednk) 

163: { 
164: r 

165: if it is a reschedule operation 

166: then insert original date/time 

167: */ 

168: GctGmfTuneString ftpGroup — xtwOldFromDateTime, 

169: IpGroup — >bHmc2onc, szTime, BUF_JUEN); 

170: LoadString (hCardfilelnstance, 

171: IDS_3KWGROUP_OLD_J)ArE_*nME, 

172: szFicld, BUF_LEN); 

173: AppendString (lp Message, szField, 

174: szSpacc, szTimc, 

175: szReturn, NULL, nSize); 

176: } 

177: 

178: // Append from and to date/time 

179: LoadString (hCardfilelnstance, 

180: IDS_SKWGROUP_FROM _DATE_TTME, 

181: szFicld, BUF_J£N); 

182: GctGmrTtmeString (IpGroup — ><rwFrooiDareTtme, 

183: 1 pGroup — >bTimeZo ne, szTune, BUF_LEN); 

184: AppendString (lp Message, szFicld, 

185: szSpace, szTune, szRetum, NULL, nSize); 

186: 

187: LoadString (hCardfilelnstance, 

188: IDS__SKWGROUP_TO_DATE_T[ME, szFtcid, BUF_LEN>, 

189: GctGmrTtmeString (IpGroup — >dWTbDaleTime, 

190: IpGroup — >bTuneZone, szTlme, BUF __LEN); 

191: AppendString (lp Message, szField, 

192: szSpace, szTlme, szRetum, NULL, nSize); 

193: 

194: // Append city and country information 

195: LoadString (hCardfilelnstance, 

196: IDS_SKWGROUP_Crry, szFicld, BUF_LEN); 

197: AppendString (lp Message, szFiekL 

198: szSpacc, IpGroup — >«zCity, 

199: szRetam, NULL, nSize); 

200: 

201 : // Append location and time zone information 

202: // <Location> location name\r\n 

203: // <Time Zone> time zone valuc\i\n 

204: // IDS_SKWGROUP_TTME_ZONE, -<Time Zone>" 

205: // IDS_SKWGROUP ^LOCATION, -<Lccation> w 

206: LoadString (hCardfilelnstance, 

207: IDS_SKWGROUP_LOCAT10N, szField, BUF__LEN); 

208: AppendString (lp Message, szFicld, 

209: szSpace, IpGroup — >«zLocatton, 

210: szRetura, NULL, nSize); 

211: LoadString (bCaidfilelnstance, 

212: IDS_SKWGROUP_TTME_ZONE, szField, BUF__LEN); 

213: ,7 rvalue - GefTimeZoneWue (IpGroup); 

214: _jloa ((inl) IpGroup — >bTlmeZone, szTune, 10); - 

215: AppendString (^Message, szFicld, 

216: szSpacc, szTune, szReturn, NULL, nSize); 

217: 

218: // Append attributes 

219: // <Attr£butes> "attribute" -attribute" . . . \r\n 

220: // IDS_SKWGROUP ^ATTRIBUTES, -<Attributes>" 

221 : LoadString (h Pitfrtfjl f T r ff^rKT , 

222: IDS_JSKWGROUP_ J ATTRlBUTES J szFicld, BUF_LEN); 

223: GetAttributeString (lpGroop, szTime, BUF_J^EN>, 

224: AppendString (lp Message, szFicld, 

225: szSpace, szTimc, szReturn, NULL, oSize); 

226: 

227: // Append Event ID1 

228: // <EventIDl> EventlDl value string\r\n 

229: // lDS_SKWGROUP _EVENT1D_1, -<EventlDl>'* 

230: LoadString (hCardfilelmtance, 
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231 : lDS_SKWGROUP_EVENTID_l , szField, BUF_LEN); 

232: _Jtoa ((long)tpGroup — xrwEventlDl, szTime, 10); 

233: AppendString (IpMessage, szField, 

234: szSpace, szTime, szRetaro, NULL, nSize); 

235: 

236: // Append Event fD2 

237: // <EvcnlID2> EvcnlID2 value string\r\n 

238: // lDS_SKWGROUP _EVENTID _2, -<EvenaD2>" 

239: LoadString (hCardfilelnstancc, 

240: IDS_SKWGROUP_EVENTID_2, szField, BUF_LEN); 

241: _Jtoa ((long) tpGroup — >dwEveniID2, szTime, 10); 

242: Append String (Ip Message, szField, 

243: szSpace, ezTime, 

244: szRetum, NULL, nSize); 

245: 

246: if (IpGroup— >wFlags & EVENT_FOKWARDED) 

247: { 

248: EACH^RECIPIENT Recipient; 

249: 

250: // append sender's name and sender's email address 

251: if (GctScndcrlnfo (IpGroup, & Recipient, B_SENDER) x- 0) 

252: { 

253: LoadString (hCardHlelnstancc, 

254: lDS_SKWGROUP_SENDER 1 _NAME, 

255: szField, BUF_JJEN); 

256: Append String (IpMessage, szField, 

257: szSpace, Recipient, szNamc, 

258: szRctura, NULL, nSize); 

259: LoadString (hCardfilelnstancc, 

260: IDS_SKWGROUP_SENDER_EMAIL, 

261: szField, BUF_LEN); 

262: AppcndStrisg (IpMessage, szField, 

263: szSpace, Recipient, szEmail, 

264: szRetum, NULL, nSize); 

265: } 

266: // append forward flag "1" 

267: LoadString (hQudfflelnstance, 

268: [DS_SKWGROUP_JS_DELEGATE, 

269: szField, BUF__LEN); 

270: AppendString (IpMessage, szField, szSpace, 

271: "1", szRetum, NULL, nsize); 

272: } 

273: 

274: // Append Text 

275: // <Subject> Text bod y </Subj ect>Vi\o 

276: // IDS_SKWGROUP_TEXT, "<Subject>" 

277: // IDS_SKWGROUP_END_TEXT, "</Subject>" 

278: if (IpGroup — >hTcxt) 

279: { 

280: LoadString (h r^frffj Mrr**»T***, 

281: [DS_SKWGROUP_TEXT, 

282: szField, BUF __LEN); 

283: LoadString (hCardfilelnstancc, 

284: CDS_SKWGROUP__END__TEXT, 

285: szTime, BUF_JLEN); 

286: IpBuf - GlofaalLock (IpGroup — >hTcxt); 

287: AppendString (IpMessage, szField, 

288: szSpace, IpBuf, 

289: szTime, szRetum, nSize); 

290: GlobalUnlock (IpGroup— >hTfext); 

291: } 

292: 

293: // Append Regarding 

294: // <Message Conteat> Regarding body</Message Content>\r\n 

295: // [DS_SKWGROUP _JlEGARDrNG, -<Message Contend" 

296: // IDS_SKWGROUP _END_REGARDING, "</Mcssage Contents 

297: if (IpGroup — >hReganting) 

298: { 

299: LoadString (hCardfilelnstancc, 

300: IDS_SKWG ROUP_REG ARDING , szField, BUF_LEN>, 

301: LoadString (hCardfilelnstancc, 

302: [DS_SKWGROUP_END_REGARD[NG, szTime, BUF_LEN); 

303: IpBuf - GlohalLock (IpGroup— >hRegarding); 

304: AppendString (IpMessage, szField, 

305: szSpace, IpBuf, szTime, 

306: szRetum, nSize); 

307: GlobalUnlock (IpGroup — >hRegarding); 

308: } 

309: // Append Delegate msg 

310: if (IpGroup— >wFlags & EVENT__FORWARDED 
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311: && IpGroup — >lpDe legate Msg) 

312: { 

313: LoadString (bCardfilelnstance, 

314: rDS_SKWGROLFP_STAKr_DELEGATE_MSG > 

315: szRcld, BUF_LEN); 

316: LoadString (hCardfilelnstance, 

317: [DS_SKWGROUP_END_DELEGATE_MSG, 

318: szTune, BUF __LEN); 

319: if (Istrlcn(IpMcssage) 

320: + lstrien (IpGroup — >lpDelegateMsg) 

321: + lstrfen(szField) + Istrlcn(siTunc) 

322: + 10 < nSize) 

323: AppendString (tpMcssage, azFtetd, 

324: szSpace, IpGroup — >tp Delegate Msg, 

325: szfllme, szReturn, nSize); 

326: } 

327: 

328: /* 

329: Append participant's name 

330: and email address to message body. 

331: V 

332: AppcndRccipientlnfo (lp Message, IpGroup, 

333: oSire, oMessageiype); 
334: 

335: /• 

336: Append resource's name 

337: and email address to message body. 

338: V 

339: if (tiMessagcType !- MSG__REMINDER) 

340: Append Rcsourcelnfo (IpMcssagc, IpGroup, 

341: oSize, nMessageType); 
342: 

343: return TRUE; 



344: } 



As its first parameter, the method is passed a pointer to the 
previously-described GROUP_APPOINTMENT data 
structure—the internal buffer storing context information 
characterizing a group scheduling event (including a 35 
message -type). At lines 29-37, local (stack) variables are 
declared and initialized. At lines 39-40, the method tests 
whether the message-type involves a resource. For a 
resource, the method will load a generic header for the 
message, at line 42. Otherwise (i.e., the "if statement 4 _ 
evahiates to "false"), the method will load into the message 
buffer, pointed to by lpMessage, a (non-resource) message 
header, provided that the message-type is Schedule, 
Reminder, Broadcast, or Reschedule. The comment set forth 
at lines 54-107 illustrates an exemplary message header. As 
shown, the message header is formatted in a fashion which 45 
permits a user having only basic e-mail support to read the 
scheduling message and reply (e.g., accept or decline) 
accordingly. 

After the message header has been loaded into the mes- 
sage buffer, the method proceeds to append to the message 
being constructed the other fields set forth in the previously- 50 
described message formats. The method proceeds as fol- 
lows. At lines 110-114, the method appends the "message- 
type" delimiter. This is followed by appending the actual 
message type for the message, at lines 116-160. Specifically, 
the method first determines the appropriate text string for the 55 
message type, at lines 117-158. Then, this message string is 
appended to the message being constructed, at lines 
159-160. 

Other fields of the message can be appended to the 
message being created in a similar manner. At lines 
162-176, the method inserts the original date/time in the 60 
event that the message is a Reschedule message. At lines 
178-192, the method appends the "from" and "to" date and 
time. At lines at 194-199, the method appends the city and 
country information, and at lines 201—216, the method 
appends location and time zone information. 65 

At lines 218-225, attribute information is appended. At 
lines 227-234 and at 236-244, the first and second event IDs 



are appended, respectively. In the event that the message 
indicates that the scheduling event has been forwarded (Le., 
delegated) to another user (tested at line 246), the method 
appends the sender's name and sender's e-mail address, at 
lines 258-265. Additionally, an "append forward" flag is set, 
at lines 266-271. 

At lines 274-291, the method appends the "subject" text. 
Any "regarding" message is appended at lines 293-308, and 
any "delegate" message is appended at lines 310-326. To 
complete the message, the participant's name and address is 
appended to the message body, at lines 329-333. Finally, 
resource information (for any resource) is appended to the 
message body, at lines 335-341. Now, the message has been 
successfully completed, and the method may return "true" at 
line 343. Once the message has been composed, it can be 
posted to the transport layer, using the previously described 
Schedule_Group_Event Method. 

Receipt of the composed scheduling message by a non- 
SK client without browser support (e.g., WordPerfect Office 
user) is illustrated in FIGS. 12A-C. FIG. 12A shows an 
e-mail viewer 1200 displaying the invitation in simple text 
format 1210. Although the message also includes richer 
formats (e.g., Attachement(s) 1211), the remote system does 
not recognize them and, thus, can simply ignore them. As 
shown in FIG. 12B, the remote user can "reply" to the 
invitation using his or her own e-mail software, as shown at 
dialog 1220, and choose to include the message received 
from the sender, as shown at 1221. Following the instruc- 
tions in the e-mail invitation, the remote user, as shown in 
FIG. 12C, edits the reply 121Lz by entering an "X" in the [ ] 
Accept text string at 1213 and entering a brief message 
between the <BEGIN REPLY MESSAGE> and <END 
REPLY MESSAGE> delimiters or markers 1217. 

The above-illustrated message composition can be 
extended to automatically generate a Hypertext Markup 
Language (HTML) form as a scheduling invitation. Here, 
the HTML form is generated in a conventional manner using 
HTML code, except that instead of a user hand-crafting the 
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form, the system automatically maps the scheduling infor- 
mation into appropriate target destinations (fields, buttons, 
and labels) on the form. For instance, the following data 
fields are mapped to HTML fields: 



HTML field 


Mapped information 


Message From: 


{Initiator} 


Date/Tune: 


{Date/Time} 


Duration: 


{Duration} 


Time Zone: 


{Time Zone} 


Location: 


{Location} 


City/Country: 


{City} 


Subject: 


{Subject} 


Message: 


{Message} 



Further, the "Accept" and "Decline" responses are mapped 
to HTML buttons. 

Creation of these control in HTML is straightforward. For 
instance, the "Accept" and "Decline** buttons can be emitted 
in HTML format as: 



<HfTML> 

<BODY> 
<FORM> 

<H1> Accept and Decline Buttoos</Hl> 

<JNPUT TYPE- - Accept" VALUE-"! accept the invitation"> 

<fNPUT TYPE-*Decline" VALUE-"! decline the tnvitation**> 
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</BODY> 
</PORM> 

5 </HTML> 



Description of the HTML format is well documented in the 
trade literature; see e.g., Duncan, R., An HTML Primer, PC 
Magazine, Jun. 13, 1995, pp. 261-270. Further description 
is provided by Duncan, R., Publishing HTML Forms on the 
Web, PC Magazine, Dec. 5, 1995, pp. 391^*03. The disclo- 
sures of the foregoing are hereby incorporated by reference. 

Receipt of the composed HTML scheduling message by 
a non-SK client with browser support (e.g., Netscape Navi- 
gator user) is illustrated in FIG. 13. The remote user employs 
the browser 1300 for displaying the invitation in hypertext 
(HTML) format 1310. The scheduling data fields are auto- 
matically placed on the form as HTML form fields 1311. The 
"Accept" and "Decline** buttons, on the other hand, are 
placed as buttons 1313. The receiving user can now simply 
respond to the form, whereupon his or her answer is trans- 
mitted back to the sender. 

d. Methodology for Parsing Messages 

Methods of the present invention for identifying and 
processing incoming group scheduling event messages will 
now be described. All incoming mail is initially processed 
by a ReceiveAlUncomingMails method. In an exemplary 
embodiment, this method may be constructed as follows. 
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1: / * «.*•••♦* ...... 

2: This function will receive all incoming group event messages. 

3: •••• * * * -/ 

4: int ReceiveAlUncomingMails (void) 

5: { 

6: LPMESSAGEINFOSET tpInfoSet; 

7: int i, 

8: nlists - cScheduledlists, 

9: nWantDIg-FALSE, 

10: nResult, 

11: nPaint - FALSE, 

12: nFoldeiCreated; 

13: char szScnder[PATHMAX+l \ azTc(PATHMAX+ll 

14: srCCtPATHNAX+ll szBCCjPATHMAX+ll 

15: szSobjecrJPATHMAX+ll szTime[BUF _LEN+ll 

16: szErnaiI[651 szErnailTypcfBUF _LEN+lL 

17: szAttach[PATHMAX.+l \ azSignature( BUF_JLEN+1 \ 

18: HGLOBAL hMessage; 

19: LPSTR tpMessage; 

20: 

21: TurnOnFlashSession ( X 

22: IpMessage - AUocLockBuffer (AhMessage, NOTETEXTSIZE * 4>, 

23: if (IhMessage) 

24: { 

25: TurnOffFlashSession ( ); 

26: return FALSE; 

27: } ' ' ' " l ^ ■ 

28: 

29: LoadString (hCardfilelnstance, 

30: n>S_SKWG ROUP_SI GNATURE, szSignature, 

31: BUF_LEN); 

32: 

33: // Get email messages from FTchangt 

34: if (rsDeliverEzchange ( )) 

35: { 

36: char szFoIderNamefBUF __LEN+lJ 

37: 

38: // RcceivcAUNewMails (hCardfileWnd); 

39: RecerveAllMailsNcrw (hCardfileWnd); 
40: 

41: // Create Internet Sidekick Folder. 

42: LoadString (hCardfilelnstance, 
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43: LDS_ISK_FOLDKR_NAME, szFolderName, BUF_LEN); 

44: nFolderCreated 

45: - OcatcAFiratLcvclFoldcrlnDefaultMsgStore 

46: { 

47: bCardfiJeWnd, 
48: szFolderNamc 

49: }; 

50: 

51: 

52: // Search for ISK Messages. 
53: lpInfoSet 

54: - SearcliSKWSchedtileMsglnlnboxFolder 

55: { 

56: hQudfiJeWnd, 

57: szSignature 

58: }; 

59: 

60: 

61: if (I lpInfoSet) // not enough memory 

62: { 

63: UnlockFrce Buffer (hMcssage); 

64: TuraOffFUshScssion ( ); 

65: return FALSE; 

66: } 
67: 

68: if (lpInfoSet — xilCount) 

69: { 

70: for (i-O, i<(int)lpIiifoSet — >ul count; i++) 

71: { 

72: if (GetMessageContents (hCardfileWnd, 

73: lpInfoSet— >lpMsgInfo (iJlpEia 

74: szScndcr, PATHMAX, 

75: szEimul, 64, 

76: szEmainype, BUF_J_£N, 

77: s/To, PATHMAX, 

78: szCC, PATHMAX, 

79: azSubject, PATHMAX, 

80: lpMessage, NOTETEXTSIZE * 4, 

81: szTime, BUF_LEN, 

82: szAttach, PATHMAX)) 

83: { 

84: 

85: trim_start_end (szScndcr, T, V); 

86: trim_starL_cnd (szScndcr, V\ *\"); 

87: trim_atarL_end (szEmaiL *\P, 4 \"); 

88: trim_start_end (szEmail, V, V); 

89: trim_start_cnd (szTb, V, 

90: trim_jtfart_cnd (szTb, T*, V'X 

91: 

92: if(!(nResult 

93: - RecciverMessageHandter (szScndcr, 

94: &zEmail, szEmaitType, 

95: szTb, szCC, szSubject, 

196: lpMessage, szAttach, 

97: FALSE))) 

98: continue; 

99: 

100: nPaint - TRUE; 

101: SetMaflRead (hCardfileWnd, 

102: lpInfoSet— >lpMsgInfo[iJJpEID); 

103: if (! IsLeaveOnScrver ( )) 

104: Delete Mail (hCardfileWnd, 

105: lpInfoSet — >lpMsgInfo [ij. IpEID, 

106: TRUE); ' ' - 

107: else 

108: { 

109: if (nFolderCreated) , 

110: MovelSKMaflsTblSKMailFolder 

111: { 

112: hCardfileWnd, 

113: lpInfoSet— >lpMsgInfo[i].IpEID, 

114: szFoIderName 

115: }; 

116: } 

117: } 

118: } 

119: } 

120: FreeMessagelnfoSet (IpInfoSetX 
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123: // Get email messages from POP3 account. 
124: if (IsDclivcrOwnlntcmct ( )) 

125: { 

126: if (SFMailGctNcw (bCardJUeWnd, szSignature)) 

127: { 

128: if (SFMailBoxOpen ( )) 

129: { 

130: IpInfoSct - SPMaflScanMail (bcardfileWod); 

131: ifflpInfoSct) 

132: { 

133: for (i-0; t<int)tpInfoSet— MilCount; i++) 

134: { 

135: if ( SFGetMessageCoatents 

136: { 

137: bCardfileWnd, 

138: IpInfoSet— >tpMsglnfo(i].IpEID f 

139: azEmail, 64, 

140: szScndci, PATHMAX, 

141 : //szEmailTypc, BUF_LEN, 

142: uTo, PATHMAX, 

143: szCC, PATHMAX, 

144: szBCC, PATHMAX, 

145: szSubject, PATHMAX, 

146: Ip Message, NOTETEXTSIZE • 3, 

147: szAttach, PATHMAX, 

148: saTime, BUF_JUEN 

149: } 

150: } 

151: { 

152: 

153: trinLJtart_cttd (szSendcr, V, V); 

1 54: trim_$tart_end (szSender, Y ', T *); 

155: lrinx_5tart_cnd (szEmafl, "\'% *\"); 

156: trim_start_end (szEmail, V\ V); 

157: trim _start_end (stflb, 'V\ V); 

158: trim_5tart_cnd (szttb, Y\ V); 
159: 

160: if (!(nResult 

161: - ReceiverMessageHandler 

162: { 

163: szSendei, 

164: nrFmai\ l 

165: szEmailTypc, 

166: szTo, azOC, 

167: szSubject, lpMcssagc, 

168: szAttach, FALSE 

1»: }}} 

170: continue; 

171: nPaini - TRUE; 

172: // delete message from inbox. 

173: if (nRcsult) 

174: SFDeleteMcssage 

175: { 

176: hCardfileWnd, 

177: IpInfoSet— >lpMsgInfo [iLlpEID 

178: }; 

179: } 

180: } 

181: } 

182: SFMaflBaxdose ( ); 

183: } 
184: } 
185: } 

186: ..... 
187: // unlock and free message block 
188: UalockFrec Buffer (hMessage); 
189: 

190: TurnOffFlashSrssinn ( X 
191: if (npaint) 
192: { 

193: if (bCoverPageWnd && IsGroupPageFront ( )) 

194: { 

195: Sort_GroupEventList (hCoverPageWnd, NULL, 

196: Get_Current_SortFiag ( )); 

197: if (InLists) 

198: { 

199: } 

200: } 

201: else 

202: SortGroupEvcntlnfb (hSchcduledList, cScheduledLists, 
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203: Get_OiiTcnt_SortFlag ( )); 

204: } 

205: return TRUE; 
206: } 



After initializing local (stack) variables at lines 6-19, the 
method "turns on" the "flash" session, at line 21. This sets 
a global flag for preventing re-entry, since this is a timer/ 
interrupt driven process. At lines 22-27, the method allo- 
cates a memory block for storing an incoming message. If 
the allocation fails, the method returns "false" at line 26. At 
lines 29-31, the method loads from a resource file the 
signature string (i.e., <ISK>). This string will be used to 
identify incoming group scheduling events. 

Now, the method is ready to retrieve e-mail messages 
from the user's in -box. At lines 33-121, the method retrieves 
messages for Microsoft Exchange and creates a folder for 
those messages (at lines 41-49). Now, the method searches 
in that folder for group scheduling event messages — that is, 
messages containing the identifying signature (at lines 
52-58). If at least one group scheduling event message is 
found (i.e., count is greater than zero at line 68), the method 
sets up a "for" loop at line 70, for looping through each such 
message. At lines 72-82, the message contents are extracted 
by a call to GetMessageContents. At lines 85-90, any 
trailing spaces are trimmed from this extracted information. 
As shown, the extracted information includes information 
about the sender (name), e-mail (address), e-mail-type, 
"To", "CC**, subject, message, time, and any attachment. 



Further processing is performed by a call to 
ReceiverMessage Handler, at line 93. The RecehrerMessage- 

10 Handler method provides appropriate message handling 
(action), based on the extracted or parsed message informa- 
tion. If the message cannot be handled (i.e., the "if state- 
ment at line 92 evaluates to "false"), then the method loops 
back for the next message, by executing the "continue** 

is statement at line 98. Otherwise, the message can be handled 
whereupon the method removes the message from the user's 
in-box (lines 104-106), and places it in a group scheduling 
mail folder (lines 1W-U5). Thereafter, cleanup is per- 
formed at line 120. In the event that the user's e-mail system 

20 is from a POP3 (Internet Post Office Protocol) account, the 
method executes lines 123-185. Here, the method performs 
essentially the same task as just described for a Microsoft 
Exchange mail account 

The method completes its operation by freeing up 

^ memory at lines 187-188, turning off the flash session flag 
at line 190, and repaints the user interface with the new 
information (if needed) at lines 191-204. Thereafter, all 
incoming mail has been appropriately processed, and the 
method may return "true" at line 205. 

The message handler itself, ReceiverMessageHandler, 
may be constructed as follows. 



1: /** ****** * ****** **** 

2: This function will handle incoming groop event messages. 

3 . ............. 

4: int ReceiverMessageHandler (LPSTR IpFrom, 

5: LPSTR IpEmaiL 

6: LPSTR IpEmaiJTypc, 

7: LPSTR tpTo, 

8: LPSTR hjCC, 

9: LPSTR tpSubject, 

10: LPSTR IpMessage, 

11: LPSTR tpAttachFile, 

12: tut nReplyCcode) 

13: { 

14: LPSTR IpShortMsg - NULL, IpNew - NULL; 
15: int nMsgfr) 

16: - MessageTypeParser (IpSabject, IpMessage, &ipNew), 

17: nReplyType - 0; 

18: 

19: if (nMsgID — GROUP_SCHEDULE 
20: 1 1 nMsgID — GROUP_BROADCAST 

21: j j nMsgID — GROUP_RESCHEDULE) 

22: { 

23: IpShortMsg 

24: - IsThisAutoReply Message (IpMessage, 

25: & nMsgID, 

26: & nReplyType); 

27: } 
28: 

29: switch (nMsgID) 
30: { 

31: case GROUP_REMINDER: 

32: case GROUP_SCHEDULE: 

33: case GROUP_BROADCAST: 

34: return Handle_ScbccraJe_Mccring 

35: { 

36: IpFrom, IpEmatl, 

37: h^Emairiype, h/Ib, 

38: IpCC, IpMessage, 

39: IpAttachFfle, nMsgID 

40: }; 

41: 
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42: case GROUP_REPLY: 

43: return Handle _Reply 

44: { 

45: IpFrom, tpEmafl, 

46: IpTb, rpCC, 

47: lpSubject, IpMessagc, 

48: oReplyTypc, IpShortMsg 

49: }; 

50: 

51: case GROUP__FREETIME: 

52: return Create FreeTLme_Matrix_Send 

53: { 

54: IpFrom, rpEmail, 

55: IpCC, IpMessagc 

56: }; 

57: 

58: case GROUP_JtESCHEDULE: 

59: return HandJe_Rc3chedidc 

60: { 

61 : IpFrom, lp Email, 

62: IpEmailTVpe, lpTb, 

63: IpCC, IpMessagc, 

64: nRcplyCodc 

65: }; 

66: 

67: case GROUP _MEETING _NOTE: 

68: return Handle _Mecting__Notc 

69: { 

70: IpFrom, IpCC, 

71 : IpMcssage, lp Attach File 

72: }; 

73: 

74: case GROUP_CANCEL_MEEnNG: 

75: retum Bandle__CanceL3feetiiig (IpFrom, IpCC, bp Message); 

76: 

77: case GROUP _NEW_R£SOURCE: 

78: retum Handle _AddNewResource (IpFrom, 

79: tp Email, tp Message); 

80: 

81: case GROUP_RESOURCE_SCHEDULE: 

82: case GROUP_JlESOURCE_RESCHEDULE: 

83: return Handle_J*esoimx_Schediile 

84: { 

85: IpFrom, rpEmail, 

86: [pEmailType, IpTb, 

87: IpCC, IpMessagc 

88: }; 

89: 

90: case GROUP_JUiSOURC£_CANCKL: 

91: return I iand lc_Kesource_Cancc 1 (IpFrom, 

92: rpEmail, rpMcssage); 

93: 

94: case GROUP_FREE_RESOURCE: 

95: retum Handle_Free_Resourcc (IpFrom, lp Email, IpMessagc); 
96: 

97: case GROUP__TRANSFER__RESOURCE: 

98: return Hartdle_Transfer_Re30urce 

99: { 

100: IpFrom, rpEmail, 

101: lpEmailTypc, IpMessagc, 

102: tpAttachFile 

103: }; 



104: } 
105: return TRUE; 
106: } 



As shown, the method is invoked with parameters set message, on the other hand, invokes a Handle_Reply han- 
equal to the just-extracted e-mail information. After declar- dler at line 43. Other handlers are invoked in a correspond- 
ing local variables at line 14 the method parses out the ■ manner a list of exemplary handlers is appended 
message type, at lines 15-16. At lines 19-21, the method ^ ^ ,w Ddix B . 
examines whether the message is one which it can auto- *^ 

matically reply to; such a condition holds true when the WmIe tbe invention is described in some detail with 

message is for a Group Schedule, Broadcast, or Reschedule. specific reference to a single preferred embodiment and 

At lines 20-104, the method establishes a case statement certain alternatives, there is no intent to limit the invention 

which switches on message type or ID, for invoking more l ° that particular embodiment or those specific alternatives, 

specialized handlers. Group Reminder, Schedule, and 65 Thus, the true scope of tbe present invention is not limited 

Broadcast messages, for instance, invoke a Handle_ to any one of the foregoing exemplary embodiments but is 

Schedule_Meeting handler at line 34. A group reply instead defined by tbe appended claims. 
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APPENDIX A 



Exemplary Message Formats 



Group scheduling format design 

1. Internet appointment message format 

Every type of message will have folio wing two parts at least. 

<Product Signaturo <ISK><or <SIS>) 

<Message Typc> <Schedule | Broadcast | Reply | Free Time | Reminder | 

Reschedule | Meeting Note | Cancel | Recurring | New Resource | Resource | Action | 
Synchzc<nizatioxi> 
Schedule and Broadcast: 

<Fram Date Timo > YY/MM/DD HlfcMM 
<To Date Timo YY/MM/DD HHiMM 



<Location> 
<Qty> 

<Timc Zonc> 
<Attribute3> 
<EventIDl> 
<EventID2> 
<Sabject> 



Place name where the *w**ing will be held. 

City name where the meeting will be held. It is related to Time Zone. 
<Tune zone name where appointment time is based on> 
<Alarm> 

A unique ID for the event 
The second part of the ID. 
<Message text></Subject> 
<Message Content> <Regardtng tettx/Message Content* 

<Participants> :- "Name; Email address; Email Type" "Name; Email Address; 

Email Type™ ^Parucipants> 

<OC> "Name; Email address; Email Type" "Name; Email Address; Email Type" 
</CO 

<Room>:- "Name; Email address; Email Type** "Name; Email Address; Hinail Type** 
</Room> 

<Equipment>:- "Name; Email address; Email Type" "Name; Email Address; Email Type" 
</Equipmcni> 

If this message is a broadcast message, it requires no ACCEPT response. 

<Reply Types> :- <Accept | Decline | Reschedule Required | Sleep | Forward | 

Resource | Free Time> 

<ForwardTb> <Name; E-mail address; Email Typex/Forward Tb> 

« If Reschedule required 

<From Date Ttme> :- YY/MM/DD HH:MM 
<To Date Time> YY/MM/DD HHiMM 

» 

<EvcntlDl> A unique ID for the event. 

<EvcntID2> The second part of the ID. 

<Short Mcssage> <Short text message x/Sho it Messago 

«If it is a Reschedule Required, Free Time Request, or Resource Reservation type of 

Schedule 

There is a file attached on this message 

The Reschedule Required type of reply is for the purpose of rescheduling right away. For 

example, a person received a group meeting request He does not have free time. So he 

requires to reschedule the meeting with different tune. 

The purpose of Sleep type is for people on vacation or leaving. 

Free Tune: (A Free Time request message) 

<EventIDl> A unique ID for this Free Time request 

<EvenlID2> The second part of the ID. 

<From Date Time> :- YY/MM/DD HHA4M 

<0b Date Timo YY/MM/DD HH:MM 

<Subject> :- <Message text></Subjcct> 

This is an auto reply message request The reply result of Free Time report is a text matrix 

with 0 and 1. 

Reschedule: 

<Oid Datc/Tuno :» YY/MM/DD; HHiMM. 

<From Date Timo :- YY/MM/DD HILMM 

<To Date Timo :- YY/MM/DD HH:MM 

<Location> :- Place name where the meeting wiil be held. 

<Qty> :- City name where the meeting wiil be held It is related to Time Zone. 

<Time Zone> :- ^Tune zone name where appointment time is based on> 

<Attrtbutes> :- <Alarm | Previously Status: Accept; Dedine> 

<EventIDl> :- A unique ID for the event 

<EventID2> :- The second part of the ID. 

<Subject> :- <Message text></Subject> 

<Message Content> <Regarding text></^bject> 

<Participanis> :- "Name; Email address; Email Type** "Name; Email Address; 
Email Type** </Participant8> 

<CC>^ "Name; Email address; Email Type" "Name; Email Address; Email Type** 
<JCC> 

<Room> :- "Name; Email address; Email Type" "Name; Email Address; Email 

Type"</ 

</Room> 
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Exemplary Message Formats 

<Equipment> :- "Name; Email address; Email Type" "Name; Fjimil Address; Email 

Type"<tf 

</EquipmcnI-> 

If this meeting is previously accepted, then a forced change appointment list will happen. If 
this meeting is previously dtdirrd or not responded, then it is handled like a normal schedule 
request. 

A Resource request message will be sent again when a Reschedule message is sent 
Reminder: 



:- YY/MM/DD HH:MM 
> YY/MM/DD HHlMM 
Place name where the wwKng will be held. 

City name where the meeting will be held. It is related to Time Zone. 
<TIme zone name where appointment time is based on> 
<Alann |l Previous Status: Accept; Declino 
A unique ID for the event 
The second part of the ID. 
<Message text></Subject> 
:- <Regarding textx/Message Oontent> 



<From DateTimo 
<To Date Tune> 
<Location> :- 
<Oty> :- 
<Time Zono 
<Attribotes> :« 
<EvmtIDl> :- 
<EvcntID2> 
<Subject> :- 
<Message Content> 
#if not Broadcast 

<Participants> "Name; Email address; Email Type" "Name; Email Address; 

Email Type" </Participants> 

<OC>:- "Name; Email address; Email Type" "Name; Email Address; Email Type" 

<JCC> 

<Room> :- "Name; Email address; Email Type" "Name; Email Address; Email 

Type"</ 

</Room> 

<Equipment> "Name; Email address; Pmnil Type" "Name; F™fl Address; Fmafl 

Typc"</ 

</Equipment> 

If this meeting is previously accepted, the ACCEPT button will be grayed out If this meeting 
is not responded, it is handled like a normal ftrhftrfnlf: 
Meeting Note: 



<Fram DateTimo 
<Tb Date Timo 
<Location> 
<Oty> 
<Tune Zono 
<EventIDl> 
<EvcntID2> 
<Subject> 
<Meeting Noto 
Cancel a group meeting: 



<EventIDl> A unique ID for the event. 

<EvcntID2> > The second part of the ID. 
<Subject> :- <Message text></Subject> 
<Short Message > <Message tcxtx/Short Message > 

Resource: (Resource Reservation Message) 



:- YY/MM/DD HHiMM 
:- YY/MM/DD HH:MM 
Place name where the ifv**i*ig was held. 

City name where the meeting will be held. It is related to Time Zone. 
^Time zone name where appointment time is based on> 
A unique ID for the event 
The second part of the ID. 
<Message lext></Subject> 

The meeting note text</Mecting Noto 



<From Date Timo 
^Ib DateTimo 
<EventIDl> :- 
<EventID2> 
<Subject> :» 
<Message Content> 
Schedule a recurring Appointment: 



YY/MM/DD HHiMM 
:- YY/MM/DD HH:MM 
A unique ID for the event 
The second part of the ID 
<Message text> </Subject> 

<Regarding textx/Message Cbntent> 



<Start Dato :- 
<End Dato :- 
<From Date Timo 
<To Date Timo 
<Recur Pattern 1> 
<Recur Pattern 2> 
<Recur Pattern 3> 
<Location> 
<Oty> 

<Time Zone> 

<Subject> 
<Message Content* 



YY/MM/DD 
YY/MM/DD 

YY/MM/DD HH:MM 
YY/MM/DD HH:MM 
Month | Week | Day 
Frequency 
:™ T nrh'^ft and FrriiiA» 
Place name where the meeting will be held. 

City name where the meeting will be held. It is related to Time Zone. 

<Time zone name where appointment time is based on> 

<Alarm> 

<Message text></Subject> 

:- <Regarding textx/Message Content> 



Firrniring an Action cross the servcrless network: 



<From Date Timo YY/MM/DD HH:MM 

<To Date Timo ^ YY/MM/DD HH:MM 

<Location> :« Place name where the meeting will be held. 
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Exemplary Message Formats 



<City> :- 
<TIme Zone> 
<EvcndDl> 
<EvcntID2> 
<Subject> :■> 
<Messagc Content> 
<Actton Item> 
recognized in Sidckick> 
Synchronizing files cross the network: 



City name where the meeting will be held It is related to Tune Zone. 
<fTime zone name where appointment tune is based on> 
A unique ID for the event. 
The second part of the ID. 
<Message text></Subject> 
:= <Rcgarding tcxtx/Mcssagc Contcnt> 

<Java applet | An executable program j operations which can be 



<From Date Tirno > YY/MM/DD HH;MM 
<To Date Tune> :- YY/MM/DD HHiMM 

<Lccation> Place name where the meeting will be held. 

<City> :- City name where the meeting will be held. It is related to Time Zone. 

<Time Zone> <Tunc zone name where appointment time is based on> 

<£ventIDl> := A unique ID for the cvenL 

<EvcntID2> :- The second part of the ID. 

<Subject> :- <Message text></Subjed> 

<Message Content> :- <Regarding textv^Message Content> 

<File Nam or- <Fi)c name which needs to be synchronized> 

Resource scheduling requires non-overlapped time and a subject The scheduling is a 
non-negotiable process. The reply only has two options: Accept and Decline. 



APPENDIX B 



Exemplary Message Handlers for Actions 

/** * 

..................................... .. y 

int Handle_5chedule_Meeting (LPSTR lpFrom, 
LPSTR IpEmail, 
LPSTR IpEniairTypc, 
LPSTR IpTb, 
LPSTR lpCC, 
LPSTR tpMcsaagc, 
LPSTR tpAttachFilc, 
int nMsgfD) 

// This function will scan the incoming message and get all the 
// information related to this event 



// Information includes following parts: 

// - start date/time and end date/time 

// - time zone 

// - location 

// - City and country 

// - Event properties, such as alarm, tentative, RSVP, etc. 

// - Participants info 

// - Resource allocated for this event 

// - Event ID 

// - Subject 

// - Message body 



// After getting the information, it will add one item into Event List 
// database 

// This function will also handle the Reminder and Confirm message type 

// 

return TRUE; 

} 

" *'*** * ***** * * ****•/ 

int Handle^RescheduIe (LPSTR lpFrom, LPSTR IpEmail, LPSTR IpEmailType, LPSTR 
tpTo, LPSTR lpCC, LPSTR IpMcssage, int nReplyCode) 

// This function will scan incoming message and get all the information 
// It will set new value to the same item in the Event database 

} 

/ * ***** 

* * ****** * **** **•*/ 

int Handle_RepIy (LPSTR lpFrom, LPSTR IpEmail, LPSTR IpTo, LPSTR lpCC, LPSTR 

foSubject, LPSTR tpMessage, int nlnReplyType, LPSTR IpShortMsg) 

{ 

1. Get group schedule information included in rpMessage; 

2. Get Reply type information included in IpMessage; 

3. Handle Group Meeting update, including change recipient status, 
change recipient if it is a forward to type of reply. 
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Exemplary Message Handlers for Actions 



} 

/" * • ... 

................................... • / 

int CrcaicFrccTunc_Matrix_Scnd (LPSTR IpFrom, LPSTR tpRmnfl, LPSTR IpCC, LPSTR 

IpMessage) 

{ 

// Create a free tune calendar and scad to initiator 

} 

/" 

„......, 

int Handk_Mccting_Notc (LPSTR IpFrom, LPSTR IpCC, LPSTR Ip Message, LPSTR 
IpAttachFOc) 

{ 

// get minutes of meeting and attached fUe and 
// save to the Event 

} 

/ * 

/ 

int Handle Cancel_Meeting (LPSTR IpFrom, LPSTR IpCC, LPSTR IpMessage) 
{ 

// get information from message 

// delete event from calendar 

// set current event to canceled status 

} 

/ * * * 

/ 

int Handk_JlescHuix_3chedule (LPSTR IpFrom, LPSTR Ip Email, LFSTR IpEmaiiTvpe, 

LPSTR IpTo, LPSTR IpCC, LPSTR IpMessage) 

{ 

// get information from message 

// try to reserve the resource 

// send reply back to initiator (accept or decline) 

} 

...................... 

.„...„„„., 

{ 

int Handk_Jtesource_CanceI (LPSTR IpFrom, LPSTR lpEmaiL LPSTR IpMessage) 
// cancel resource reservation 

} 

/..,.......„........,.,..,......,.....................,...,...,..,............. 

••• .............. 

{ 

int Handle __Free _Resource (LPSTR IpFrom, LPSTR Ip Email, LPSTR IpMessage) 
{ 

// create resource free time calendar and send to intiator 

} 

/ 

* / 

int Handle_Transfer_Kesource (LPSTR IpFrom, LPSTR Ip Email, LPSTR IpEmaOType, 

LPSTR tpMessage, LPSTR tpAUachFilc) 

{ 

// get transfer resource and add an item to event database 

} 



What is claimed is: SO 
1. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: — 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to ss 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 60 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 

a plurality of different message formats, each message 
format supporting a different level of information 
content, said plurality of different message formats 65 
selected from a group comprising at least a proprietary 
scheduling format, a Hypertext Markup Language 



(HTML) format, and a simple electronic-mail format so 
that said scheduling invitation may be encoded for 
appropriate processing by disparate remote computer 
systems including those which are unable to interpret 
proprietary scheduling formats of the computerized 
scheduling system of the user; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 
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(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply. 

2. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 5 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are to 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user, 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 15 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant. ^ 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and ^ 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein at least one message format comprises a pro- 35 
prietary scheduling format of the computerized sched- 
uling system of the user. 

3. The method of claim 2, wherein said message format 
which comprises a proprietary scheduling format of the 
computerized scheduling system of the user is transmitted in ^ 
the electronic scheduling message as a binary attachment 

4. The method of claim 3, wherein said binary attachment 
comprises a Multipurpose-taternet-Mail-Extensions binary 
attachment. 

5. The method of claim 1, wherein at least one message 45 
format comprises a simple text message ensuring that a 
participant employing a computer system providing only 
simple electronic-mail support can reply to said electronic 
scheduling message. 

6. Hie method of claim 1, wherein said input received 50 
from the user comprises an event time and location. 

7. The method of claim 6, wherein at least one of the 
scheduling replies comprises a reply indicating that ,a j>ar-, 
ticipant cannot participate in the event and further includes 
information indicating an alternate time for scheduling the 55 
event. 

8. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 60 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 65 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
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the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein said message format which comprises a 
Hypertext Markup Language (HTML) form automati- 
cally generated by the system based on said input from 
the user, said HTML form capable of being viewed by 
any participant having an HTML browser. 

9. The method of claim 8, wherein said HTML form 
comprises form fields displaying said input from the user, 
and further comprises screen buttons which a participant can 
select for generating a reply. 

10. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein said a different level of information content 
comprises selected ones of a proprietary scheduling 
format of the computerized scheduling system, a 
Hypertext Markup Language (HTML) format, and a 
simple text format 

11. The method of claim 1, wherein said electronic 
scheduling invitation includes an embedded identifier which 
is incorporated into each reply so that said computerized 
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scheduling system can automatically differentiate the replies 
from other electronic mail which the user receives. 

12. The method of claim 11, wherein said embedded 
identifier includes information allowing said computerized 
scheduling system to automatically identify the replies as 
being associated with a particular electronic scheduling 
invitation. 

13. The method of claim 1, wherein each reply includes 
a participant identifier allowing said computerized schedul- 
ing system to automatically associate each reply with a 
particular participant. 

14. The method of claim 13, wherein step (e) includes 
indicating in the calendar which participants can attend. 

15. The method of claim 1, wherein step (c) includes: 
transmitting said scheduling invitation via a particular 

electronic-mail format of America On-line, 
CompuServe, Microsoft Exchange, and Internet POP3, 
wherein the particular electronic-mail format employed 
is selected based on an electronic-mail address for each 
participant 

16. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system, said plurality formats 30 
selected from a group comprising at least a proprietary 
scheduling format,, a Hypertext Markup Language 
(HTML) format, and a simple electronic-mail format so 
that said e-mail invitation may be encoded for appro- 
priate processing by disparate e-mail systems including 
those which are unable to interpret proprietary sched- 
uling formats of said automated electronic scheduling 
system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 45 
from each reply information indicating whether a 
desired participant can attend the particular event. 

17. The system of claim 16, further comprising: 

a calendar update module for automatically indicating 
which desired participants can attend the particular 
event. 

18. The system of claim 16, wherein said composer inserts 
.an identifier, .into the e- m ail .-in vi ta no n so that any reply 

which incorporates contents of the e-mail invitation can be 
associated with the particular event 

19. The system of claim 18, wherein said identifier is 
inserted into a subject line of the e-mail invitation. 

20. The system of claim 16, wherein said composer inserts 
into the e-mail invitation for each particular desired partici- 
pant an identifier for the participant so that any reply which 
incorporates contents of the e-mail invitation can be asso- 
ciated with the particular desired participant 

21. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 
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a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
wherein said formats comprise at least a simple text 
message understood by any participant having a system 
with simple e-mail support, a Hypertext Markup Lan- 
guage (HTML) form understood by any participant 
having a system with an Internet browser, and a binary 
attachment understood by any participant having the 
automated electronic scheduling system. 

22. The system of claim 21, wherein said simple text 
message includes delimiters for recording a desired partici- 
pant's response in a manner which can be identified by the 
parser. 

23. The system of claim 22, wherein said delimiters 
comprise text strings having a form substantially like [ ] 
Accept and [ ] Decline, for allowing a desired participant to 
indicate whether the participant can attend the particular 
event 

24. The system of claim 22, wherein said delimiters fur- 
ther comprise text strings having a form substantially like 
<BEGIN REPLY MESSAGE> and <END REPLY 
MESSAGE>, for allowing a desired participant to enter a 
reply which is automatically recognized and processed by 
the system. 

25. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and * - - ;^ v=^.. vvr ^^..-." - ; • - ^ 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
wherein said e-mail transport mechanism is a selected 
one of a Microsoft MAPI (Messaging Application 
Programming Interface) compliant e-mail transport 
mechanism and a POP3 (Internet Post Office Protocol) 
compliant e-mail transport mechanism. 

26. A method for unattended scheduling of resources, the 
method comprising: 

storing in a computer information describing a set of 
resources which are available for use by individuals; 

providing at least one electronic mail (e-mail) account at 
the computer for receiving e-mail scheduling requests 
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from the individuals for scheduling use of the resources 30. The method of claim 29, wherein said movable type 

at particular times; 0 f resource includes an "equipment" resource type. 

n™£ XTfrr^^J^r't rf^ ""T^ 31. The method of claim 29, wherein said immovable type 

processing the e-mail request for identifying a particu- c 9 

lar individual who is requesting a particular resource at 5 of resource includes a "room" resource type. 

a requested time; 32. The method of claim 31, wherein said scheduling 

comparing the received request against a scheduling cal- calendar also maintains schedules for meetings of the inch- 

endar listing availability of the particular resource at victuals and wherein individuals are not allowed to schedule 

the requested time, and two meetings which require an identical resource which is of 

if the particular resource is available at the requested time, JQ "room " 

automatically sending a reply e-mail message to the 

particular individual confirming acceptance of the 33. The method of claim 29, wherein a resource which is 

scheduling request and updating the scheduling calen- immovable is not allowed to accept scheduling requests 

dar for indicating that the particular resource is now specifying times which overlap. 

utcu^dl^ ^ rcqU£Sted time fOF by tbe partJcu,ar 15 34. The method of claim 29, wherein a resource which is 

27^ method of claim 26, further comprising: mOVab ^^J^ t0 aCCept **<^& »q™** specifying 

if the particular resource is unavailable at the requested hmes over P- 

time, automatically sending a reply e-mail message to 35. The method of claim 26, wherein said processing the 

the particular individual denying acceptance of the e-mail request includes parsing the e-mail request to extract 

scheduling request. 20 ^ identifier indicating that the e-mail is a scheduling request 

28. The method of claim 27, wherein said reply e-mail f or a resource 

message fwtber comprises a report indicati.* availability of J6 ^ ^ f ^ ^ 

the particular resource for a given time period. ' M uiu* 

29. The method of claim 26, wherein said set of resources 15 automatically converted by the system to a time zone 
include at least two types of resources selected from a 25 native to where the particular individual resides, 
movable type of resource and an immovable type of 

resource. * ♦ * # * 



d2) United States Patent 

Pivowar et al. 



lOllllJIIIIIIIIlllllHiEiU 

US006466236B1 

(io) Patent No,: US 6,466,236 Bl 
(45) Date of Patent: Oct. 15, 2002 



(54) SYSTEM AND METHOD FOR DISPLAYING 
AND MANIPULATING MULTIPLE 
CALENDARS ON A PERSONAL DIGITAL 
ASSISTANT 

(75) Inventors: Alvin Pivowar; Steve Hanrahan; Pete 
Grillo, all of Portland, OR (US) 

(73) Assignee: Palm, Inc., Santa Clara, CA (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/288,774 

(22) Filed: Apr. 8, 1999 

(51) Int. CI. 7 G06F 3/00 

(52) U.S. CI 345/835; 345/864; 345/963 

(58) Field of Search 345/326, 329, 

345/333, 334, 339, 340, 348, 350, 351, 
352, 354, 357, 963, 169, 173, 700, 703, 
733, 744, 764, 765, 775, 776, 781, 810, 

835, 840, 843, 864, 854, 866; 705/8, 9 

(56) References Cited 

U.S. PATENT DOCUMENTS 



4,831,552 A * 5/1989 Scully et aL 345/329 

5,129,057 A * 7/1992 Stropc et aL 345/348 

5,214,768 A 5/1993 Martin et al 711/114 

5,261,045 A 11/1993 Scully 345/751 

5,412,791 A 5/1995 Martin et al 711/114 

5,457,476 A ♦ KV1995 Jenson 345/146 

5,479,411 A 12/1995 Klein 379/88.13 

5,528,745 A ♦ 6/1996 King et al 345/326 

5,557,659 A 9/1996 Hyde-Thompson 379/88.13 

5,572,643 A 11/1996 Judson 709/218 

5,621,458 A * 4/1997 Mann et al 348/232 

5,647,002 A 7/1997 Brunson 709/206 

5,684,990 A 11/1997 Bootfaby 707/203 

5,740,549 A 4/1998 Reffly et al 705/14 

5,745,884 A 4/1998 Carnegie et aL 705/34 

5,790,974 A 8/1998 Tognazzini 701/204 



5,809,242 A 9fl998 Shaw et al 709/217 

(List continued on next page.) 

FOREIGN PATENT DOCUMENTS 

WO WO99/06900 11/1999 

OTHER PUBLICATIONS 

Puma Technology, Intellisync, http://www.pumatech.com/ 
intellisynchtml, Feb. 22, 1999. 

TrueSync Technology, TrueSync Tehcnology Platform, 
hUp://www^tarfich.com/products/tmetech/truetech.htn^ 
Feb. 22, 1999. 

When.com, What is When.com?, http://www.when.com, 
Apr. 7, 1999. 

PointCast, PointCast Network, http://www.pointcast.com/ 
products/pcn/index.html?homepb, Apr. 7, 1999. 
PointCast, PointCast Network, http://www.pointcast.com/ 
products/pcn/hwork.html?pcnidxbody Apr. 7, 1999. 

Primary Examiner — CresceUe N. dela Torre 

(57) ABSTRACT 

A portable, hand-held personal digital assistant is provided 
for simultaneously depicting multiple calendars on a single 
display. The personal digital assistant includes a portable, 
band-held housing including a top face, a bottom face, and 
a side wall therebetween for defining an interior space. An 
input device is situated on the top face of the housing for 
allowing input of data. Associated therewith is a display 
situated on the top face of the housing for depicting data. 
Situated in the interior space of the bousing is memory for 
storing a plurality of calendars each including a plurality of 
scheduled matters. Finally, controller, is situated in the 
interior space of the housing and connected between the 
input device, the display, and the memory. The controller 
serves for simultaneously depicting a plurality of the calen- 
dars on the display. By conveniently displaying the multiple 
calendars, the present invention allows a user to more 
effectively manipulate the same. 
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SYSTEM AND METHOD FOR DISPLAYING a plurality of users may be networked to a single computer, 

AND MANIPULATING MULTIPLE or server, which stores calendars for the users. During 

CALENDARS ON A PERSONAL DIGITAL operation, each of the users may utilize the server in order 

ASSISTANT to access and manipulate his or her calendar. One example 

5 of this can be found on the Internet, wherein various client 

CROSS REFERENCE TO RELATED computers may be connected to the Internet and access one 

APPLICATIONS of a plurality of calendars on a single server via a web site. 

The present application is related to co-pending applica- . ™ e * ntc ™* has ^^ultiple users to access a 

tionsentitied "System and Method for Syirchroniz^ Mul- in sm & ***** c ^ du ±^\ system permits each user 

tiple Calendars over a Wide Area Network" byfaventors 10 10 ™ w *f <** vanous f bcduled malters on ^ 

Alvin Pivowar, Steve Hanrahan and Pete GriUo, Ser. No. ^ f " OV T t ll Q dw ™«^™y^«^ to 

09/289,764, filed concurrently herewith, and incorporated ™ b ° f tbe Jf^ of ^ cach tune me ^ 

herein by reference; "System and Method for Sharing Data caJendar 15 edlted * 

Among a Plurahty of ftsrsonal Digital Assistants" by Inven- Io cono* 3 ^ PDA's currently do not allow the 

tors Alvin Pivowar, Steve Hanrahan and Pete GriUo, Ser. No. display, let alone the storage of multiple calendars. This is a 

09/289,771, filed concurrenUy herewith, and incorporated result of both intended purpose of PDA's and 

herein by reference; "System and Method for Synchronizing ^° various technical limitations. For instance, PDA's are 

Data Among a Plurality of Users Via an Intermittently traditionally employed for the storage and manipulation of 

Accessed Network" by Inventors Alvin Pivowar, Steve personal data, hence the name personal digital assistant. As 

Hanrahan and Pete Grille, Ser No. 09/289,769, filed con- 20 such > PDA ' S conventionally allows the storage of only a 

currently herewith, and incorporated herein by reference; sm 8* e personal calendar. 

and "System and Method for Advertising during a Data Even if the storage of multiple calendars on a PDA were 

Transfer Process" by Inventors Alvin Pivowar, Steve Han- desired, many technical obstacles prevent such implemen- 

rahan and Pete Grillo, Ser. No. 09/289,273, filed concur- tation. This is at least partly due to the portable nature of 

rently herewith, and incorporated herein by reference. PDA's which mandates that the various components of 

PDA's, including the displays, are extremely compact. This 

FIELD OF THE INVENTION feature tends to preclude a feasible method of displaying the 

_ , „ .. , . multiple calendars in a way that such information may be 

Tlie present invention relates generally to delaying effectivel read ^ manipulate(L 

calendars on personal digital assistants and, more 30 _ T . . t , , . . , 

particularly, to a system and method for effectively control- ,. U P t0 M *' ^T** " d Van0U f te ^ hmcal 

f. 4 . . / . • i c i j limitations of PDA s has restricted the use of only one 

ling the presentation and manipulation of calendars on a , , „_ A _ . . ..... 7 , 

personal digital assistant calendar per PDA. This has limited PDA users to only 

organizing his or her own scheduled matters without regard 

BACKGROUND OF THE INVENTION 35 *° ^ scheduled matters of others. Inherent in this limited 

system is a potential for increased disorganization amongst 

Personal digital assistants, or PDA's, are commonly various PDA owners who interact in normal everyday life, 

known hand-held computers that can be used to store, There is thus a need a system and method for storing 

display, and/or manipulate vanous personal information multiple calendars on a PDA and further allowing the* 

including, but not limited to contact information, calendar ^ ^pUy of such calendars to enable effective retrieval, 

information, etc. Such information can be downloaded from addition, modification, and deletion of the calendars, 
other computer systems, or can be inputted by way of a 

stylus and pressure sensitive screen of the PDA or any other DISCLOSURE OF THE INVENTION 

type of input device such as a mechanical keyboard or a Aportable> hand _ held personal digital assistant (PDA) is 

voice ^recogmuon module. Examples of PDA s are the ^ for simultane^usTy depicting multiple calendars 00 

FWm™ computer of 3Com Corporation and Microsoft £ sin ^ ^ pD / m ^ ude / a ^ tmnd-held 

CE™ computers which are each available from a variety of , - . , ,/ c . 44 / ' . , „ 

vendors housing including a top face, a bottom face, and a side wall 

therebetween for defining an interior space. An input device 

Unlike PDA's, conventional desktop computers, in the ^ situated on the top face of the housing for allowing input 

past, have allowed the storage and manipulation of multiple 5Q of ^ u Associated therewith is a display situated on the top 

calendars thereon. This capability has been prompted by the face of the housing for depicting data. Situated in the interior 

fact that desktop computers are commonly utilized by mul- space of the housing is memory for storing a plurality of 

tiple users. Further, desktop computers are traditionally calendars each including a plurality of scheduled matters, 

equipped with the technical features that are necessary to Finally, control circuitry is situated in the interior space of 

enable such functionality. 55 me housing connected between the input device, the 

For example, a desktop computer commonly runs soft- display, and the memory. The control circuitry serves for 

ware that is capable of allowing various users to share a total simultaneously depicting a plurality of the calendars on the 

capacity of the computer. This may be done by allowing display. The controller is further adapted for executing 

each user to log on and retrieve, add, modify, and delete multiple methods to facilitate the simultaneous display of 

information, i.e. calendars, that are unique to such user. In 50 the calendars on the display of the PDA. By conveniently 

terms of technical features, desktops are equipped with an displaying the multiple calendars, the present invention 

abundance of memory which may be allocated to the cal- allows a user to more effectively manipulate the same, 

endars of each of the different users. Also, screens of desktop i n order to allow the storage, display, and manipulation of 

computers are typically have larger than 12" in size. This the calendars, the calendars and scheduled matters may be 

even allows multiple calendars to be displayed if desired. 65 stored in separate calendar databases. Further included is a 

Networking of computers has augmented the number of common database including a plurality of identification data 

calendars that may be stored on one computer. For instance, sets each corresponding to the calendar of one of the 
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calendar databases. Such identification data sets each FIG. 6 is a flowchart illustrating operation 516 of FIG. 5 

include attributes corresponding to the associated calendar in greater detail; 

database. Examples of such attributes may indicate that one piG. 7 is a flowchart illustrating operations 410 and 506 

of the calendars is selected, a primary calendar, read only, Q f FIGS. 4 and 5, respectively, in greater detail; 

and/or a foreign calendar. In operation, the calendars of the 5 HGgisil fiowchart acting opcralion 412 nG . 4 m 

calendar databases m accordance with the attributes that are greater detail; 

stored in the common database. 

^ L , , , j . , FIG. 9 A is an illustration of a user interface display of the 

Further, various methods may be employed to display the , a siogle m mcremente of 

calendars to allow more effective manipulation. For hours; 

example, in one embodiment of the present invention, at 10 __ A _ . M1 . „ f 

least one calendar is depicted along with a plurality of icons nG 9Blsan ill f tra f 100 of ause / ***** ***** of 

each corresponding to increments of time, i.e. hours, days, P"** Dl sowing * pair of calendars in increments 

and weeks. Next, the present invention allows the selection ofbouis don 8 ^ a maiked ofa scheduled matter, 

of one of the icons after which the calendar is divided into nG - is an illustration of a user interface display of the 

increments of time corresponding to the selected icon. As an *5 present invention showing window for selecting which 

option, the selected icon is enlarged upon a plurality of calendars are to be displayed simultaneously; 

calendars being displayed simultaneously. FIG. 9D is an illustration of a user interface display of the 

In another embodiment, upon the selection of a desig- present invention showing window for selecting which 

nated icon, a window is depicted which identifies each of the calendars are to be displayed simultaneously, wherein an 

calendars and allows the selection of the calendars by way 20 additional calendar is selected by way of a check box; 

of any graphical interface such as check boxes. Thereafter, FIG. 9E is an illustration of a user interface display of the 

the selected calendars are displayed. While the selected present invention showing three calendars in increments of 

calendars are being displayed, any of the selected calendars hours, wherein the sections corresponding to each increment 

may be replaced with another calendar using a pull-down of time is augmented since a large number of calendars are 

window. 25 displayed at once; 

In yet another embodiment, each calendar that is dis- FIG. 9F is an illustration of a user interface display of the 

played is divided into sections corresponding to increments present invention showing one calendar in increments of 

of time. Further, the scheduled matters are depicted in the hours with a marked duration of a scheduled matter along 

sections. In use, a size of the sections is altered as a function ^ with descriptive text; and 

of a number of the calendars simultaneously depicted so as FIG. 9G is an illustration of a user interface display of the 

to allow a sufficient amount of space for depicting the present invention showing a pull-down window for selecting 

scheduled matters. one of the calendars to be displayed. 

In accordance with still yet another embodiment, a user is w 

allowed to move the scheduled matters of one of the « DESCRIPTION OF THE PREFERRED 



calendars to another one of the calendars. This may be 



35 EMBODIMENTS 



accomplished by dragging the scheduled matter on the With reference to FIG. 1, a preferred embodiment of the 

display between the calendars. present invention includes a personal digital assistant (PDA) 

These and other advantages of the present invention will 100. As shown, the PDA 100 includes portable, band-held 

become apparent upon reading the following detailed 40 housing 102 having a top face, a bottom face, and a side wall 

description and studying the various figures of the drawings. therebetween for defining an interior space. Situated on the 

top face of the housing 102 is an input device 104 which is 

BRIEF DESCRIPTION OF THE DRAWINGS adapted for allowing input of data. Associated therewith are 

The foregoing and other objects, aspects, and advantages a plurality of pushbuttons 108 also for input purposes. A 

are better understood from the following detailed description 45 display 110 is situated on the top face of the housing 102 for 

of a preferred embodiment of the invention with reference to depicting data. It should be noted that the pushbuttons 108, 

the drawings, in which: input device 104, and/or the display 110 may be amalgam- 

FIG. 1 is a perspective view of the personal digital ated mto a devioe - 

assistant of one embodiment of the present invention; ^ shown m mG - 2 > memory 112 is typically situated in 

FIG. 2 is a schematic diagram showing the interconnec- 50 me ^rior space of the housing 102 In use, the memory 112 

lion of the various electrical components of the personal serves for storing a plurality of calendars each including 

digital assistant of FIG. 1; multiple scheduled matters. As shown, the memory 112 may 

, A . .„ c . . - - . c . take the form of a DRAM or ROM. Also included is a 

FIG. 3A is an illustration of a user interface display of the . „ 4 , . . 4 . c . 

. . r ^_ . , j controller 113 situated in the interior space of the housing 

present invention showing the various features associated + M « ... 4 , . , 

*. . . & 55 102 and connected between the input device 104, the display 

110, and the memory 112 via at least one bus 116. It should 

FIG. 3B is a diagram iHustrating a method of displaying ^ DOted ^ me ^^11^ 113 may include a microproces- 

multmle calendars on a display the personal digital assistant ^ ^ d accompanying software stored in the memory 112. 

of FIG. 1 in accordance with one embodiment of the present Alternatively, the controller 113 may take the form of any 

invention; 60 hardware and/or software combination that is capable of 

FIG. 3C is a block diagram illustrating a data structure in controlling the various components of the present invention 

accordance with one embodiment of the present invention; m order to carry out the intended functions. 

FIG. 4 is a flowchart illustrating a method of simulta- \ n one embodiment, the PDA 100 may include a hand- 

neously displaying multiple calendars on a display of the held Palm™ PDA available from 3Com Corporation or a 

personal digital assistant of FIG. 1; 65 Microsoft CE™ computer. In the alternative, the PDA may 

FIG. 5 is a flowchart illustrating operation 408 of FIG. 4 take the form of any other type of portable data storage 

in greater detail; module which is capable storing, editing, and/or synchro- 
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nizing sets of personal data. This may be accomplished by allowing the selection of multiple calendars to be displayed 

any type of I/O mechanisms including, but not limited to a simultaneously in the third state 304. 

display HO, a plurality of push buttons, a keyboard, a data i D the third state 304, the pull-down icon 134 of any of the 

port, an electronic writing pad using a stylus 106, a voice calendar headings 132 can be used in a mariner similar to 

recognition unit, and/or any other type of I/O device capable 5 that in the previous states in order to select one of the 

of inputting and/or outputting personal data. It should be available calendars in place of the currently displayed cai- 

noted that any of the foregoing I/O devices may be mechani- endars. Further, the calendar headings 132 may be selected 

cal in nature or, in the alternative, be incorporated into a for reverting to the second state 302, herein a single calendar 

"touch-sensitive" display. is displayed. 

During use of the PDA 100 of the present invention, 10 As shown in FIG. 3B, in each of the states, the calendars 

various features are displayed during operation in a "calen- may be divided into various selected increments of hours, 

dar" mode. For example, as shown in FIG. 3A the display days, and weeks. It should be noted that the calendars may 

110 generally includes a header 120 including a day selector include any type of calendars including a sports calendar, a 

bar 122 having a plurality of day select icons 124, a current personal calendar, a work-related calendar, and/or another 

date field 126, and a calendar select icon 128. Below the 15 person's calendar. Such calendars may be manually 

header 120 is a plurality of data fields 129 each correspond- inputted, downloaded, or synchronized in any fashion, 

ing to specific times which are identified by time identifiers jtjq 3c is a block diagram illustrating a data structure 

130. The data fields 129 also have a calendar heading 132 wnich facilitates the display of multiple calendars on a 

and an associated pull-down icon 134 positioned thereabove display 110 of the PDA 100 of FIG. 1. In order to facilitate 

for reasons that will become apparent hereinafter. 20 handling the various calendars stored within the PDA 100, 

With continuing reference to FIG. 3A, positioned along a each of the calendars and associated scheduled matters may 

lower portion of the display 110 is a time increment selector be stored in separate databases 150. Further, a common 

bar 136 including three time increment icons 140 each database 152 may be provided including a plurality of 

corresponding to a unique time increment Ideally, the icons identification data sets each corresponding to the calendar of 

of the time increment selector bar 136 include three squares 25 one of the calendar databases. 

each having a number of indicia elements that corresponds i n one embodiment, each identification data set includes 

to an associated time increment. It should be noted that when a system name, i.e. CAL0, CAL1, CAL2, etc.; a username, 

selected, the day select icons 124, time increment icons 140, i. e . Willie Mills, Dave Davies, etc.; and a plurality of 

and time identifiers 130 may be highlighted or otherwise attributes. As shown in FIG. 3C, such attributes may incfa- 

distinguisbed with respect to the remaining icons and iden- cates that one of the calendars is selected, a primary calendar 

tillers. Also shown in FIG. 3A is a new button 142, a details (default), read only, or a foreign calendar. It should be noted 

button 144, and a goto button 146. that the attributes may be selectively determined by the user 

It should be noted that while the calendars are being or automatically assigned depending on a source of the 

displayed, a user may utilize any one or more of the I/O 35 associated calendar. In use, the common database may be 

devices to create, edit, modify various aspects of the calen- referenced to display the calendars of the calendar databases 

dar information such as data, security rights, or sharing in accordance with the attributes. Further, the common 

rights. In various alternate embodiments, the foregoing database allows the scheduled matters to be shared among 

principles may also be applied to other information such as the calendar databases. 

contact information. ^ It should be noted that the data structure of FIG. 3C is 

FIG. 3B generally shows the operation of one embodi- further critical for allowing the features of the present 

ment of the present invention. In use, the controller of the invention to be utilized with PDA's that are capable of 

PDA 100 is adapted for allowing a user to simultaneously handling only a single calendar. This backwards compat- 

depict a plurality of the calendars 146 on the display 110. ibility is enabled by allowing the data of each of the 

This is accomplished by permitting operation in a plurality 45 calendars including the original calendar to be stored inde- 

of states. For example, in a first state 300, a single primary, pendently. The correlation data in the form of attributes, on 

or default, calendar is displayed. A second state 302 is used the other hand, is stored in a separate common database, 

to depict a single calendar other than the primary calendar. fig. 4 shows a more detailed flowchart of the method of 

In still yet another state, a third state 304, a plurality of simultaneously depicting a plurality of the calendars on the 

calendars may be depicted. 50 display. In operation 400 of FIG. 4, the primary calendar, as 

During use, a user may maneuver between the various indicated by the attributes, is displayed, as shown in FIG. 

states by selecting certain items on the PDA 100. For 9A. Next, in decisions 402 and 404, a wait loop is executed 

example, while in the first state 300, a user may shift to the until a multiple-view event, i.e. an event that requires the 

second state by selecting the pull -down icon 134 which in display of multiple calendars, is detected. If such event is not 

turn provides a pull-down window for allowing the selection 55 detected, the display continues normally in operation 406 of 

of any available calendars in place of the primary calendar FIG. 4. Note FIG. 9 A. 

in the second state 302. In the alternative, the calendar select i£ however, a multiple-view event is detected, it is then 

icon 128 may be selected which provides a separate full-size determined which type of multiple-view event has taken 

window for allowing the selection of multiple calendars to place. It should be noted that a multiple-view event may 

be displayed simultaneously in the third state 304. Further « include the selection of the calendar select icon 128, one of 

details regarding tbe operation of the pull -down window and the time increment icons 140, or the pull-down icon 134. If 

full-size window will be set forth later. it is Determined that one of the time increment icons 140 was 

While in the second state 302, the pull-down icon 134 selected in decision 404, the multiple views are handled in 

may be used in a manner similar to that in tbe first state 300 operation 408. If, on the other hand, it is determined that the 

in order to select one of the available calendars in place of 65 calendar select icon 128 was selected in decision 404, the 

the currently displayed calendar. Further, tbe calendar select selected calendars are handled in operation 410. Finally, if it 

icon 128 may be selected to provide the full-size window for is determined that the pull-down icon 134 was selected in 
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decision 404, Ibe calendars are picked in operation 412. the pull -down icon 134 was selected As shown, it is first 
Additional details regarding operations 48, 410, and 412 will determined whether the calendar associated with the pull- 
be set forth hereinafter with reference to FIGS. 5, 7, and 8. down icon 134 is a primary calendar in decision 800. If so, 

FIG. 5 is a more detailed flowchart delineating the method then any selected calendar is shown in addition to the 

associated with the operation 408 shown in FIG. 4 when one 5 primary calendar in operation 802. If, however, the calendar 

of the time increment icons 140 is selected. As shown in associated with the pull-down icon 134 is not a primary 

FIG. 5, it is first determined which calendars are active, or calendar and there are not many calendars that are selccted(l 

selected, in operation 500 after which such active calendars or 2), then a pull-down window 803 is displayed in operation 

are displayed side-by-side in operation 502 and divided into Note FIG. 9G. Thereafter, a new calendar may be 

the time increments associated with the time increment icon 10 selected in operation 806 after which such selected calendar 

that was selected. In other words, the calendars) is divided replaces the previous calendar in operation 808 in the 

into increments of time corresponding to one of the time corresponding section of the display. Finally, the pull-down 

increment icons 140 that is currently selected. As an option, window is disabled in operation 810. 

the selected icon may be altered, Le. enlarged, upon a With specific reference now to FIGS. 9A-9G, various 

plurality of calendars being displayed simultaneously, 15 graphical user interfaces are shown that may occur during 

wherein the selected time increment icon is augmented as a use of the present invention. FIG. 9A depicts a single 

function of a number of the calendars being displayed calendar divided into increments of hours. As shown, the 

simultaneously. Note, for example, FIGS. 9B and 9E. time increment icons 140 of the time increment selector bar 

With continuing reference to FIG. 5, after the selected 136 are of a similar size when a single calendar is displayed, 

calendars are displayed, it is then determined in decision 504 20 FIG. 9B shows a pair of calendars displayed simulta- 

whetber the calendar select icon 128 has been selected. If so, neously in a side-by-side relationship and each divided into 

the selected calendars are handled in operation 506. If not, increments of hours. It should be noted that the time 

it is then determined in decision 508 whether a specific time, increment icon 140 that corresponds to the increments of 

i.e. date, has been selected. If so, then a portion of the hours is enlarged since multiple calendars are displayed, 

process is repeated. If a specific time is not determined in 25 Further, a time duration bar 900 is included for indicating a 

decision 508, it is determined in decision 510 whether one time period during which a scheduled matter is arranged, 

of the time increment icons 140 has been selected. If so, the FIG. 9C depicts the full-size window 701 which displays 

present method ceases. If not, however, it is then determined all of the calendars available to be picked. As shown, 

whether a calendar heading 132 or an event, Le. scheduled checkboxes 703 are available to facilitate such selection. As 

matter, has been selected in decisions 512 and 514, respec- 30 mentioned earlier, in order for the full-size window 701 to 

tively. Thereafter, the calendar heading 132 or event is be displayed, the calendar select icon 128 of FIG. 3A must 

handled in operations 516 and 518, respectively. be selected. FIG. 9D also shows the full-size window 701, 

FIG. 6 is a more detailed flowchart illustrating the method hut with an additional selected calendar. As shown, selection 

associated with operation 516 shown in FIG. 5. In particular, °f a calendar is facilitated by way of a highlight bar 903. 

as shown in decision 600 of FIG. 6, it is first determined FIG. 9E depicts three calendars displayed simultaneously 

whether there is more than one calendar displayed on the in a side-by-side relationship and each divided into incre- 

PDA 100 or, in other words, whether the present invention ments of hours. As shown, the sections of each calendar are 

is operating in the third state 304 of FIG. 3B. If the present enlarged to compensate for the smaller areas in which the 

invention is operating in the third state 304, details relating ^ calendars are fitted. In the present display, the time incre- 

to the instant event, or scheduled matter, are presented in an meat icon 140 that corresponds to the increments of hours is 

unillustrated pop-up window in operation 602. At that point, enlarged. 

the user may decide whether to move the instant event in FIG. 9F shows a single calendar similar to that of 9A with 

decision 604. If so, in operation 606, the event may be the exception of an open appointment icon 902 that indicates 

moved to another one of the simultaneously displayed 45 that a specific time period is open. FIG. 9G is an illustration 

calendars by dragging the scheduled matter on the display showing the pull-down window 803 which may be accessed 

between the calendars using the stylus 106 or any other input by selecting the pull-down icon 134. In one embodiment, the 

device. pull-down window requires only a part of the display 110 of 

With continuing reference to FIG. 6, it is shown that the the PDA 100. As shown, a currently selected calendar is 

events, or scheduled matters, of the calendars may be 50 indicated by way of a highlight bar 904. 

modified. This is accomplished by first determining whether While various embodiments have been described above, 

the detail button 144 has been selected in decision 608. If it it should be understood that they have been presented by 

has, the event is displayed in operation 610 for modification way of example only, and not limitation. Thus, the breadth 

if desired in operation 612. and scope of a preferred embodiment should not be limited 

FIG. 7 is a more detailed flowchart delineating the method 55 by any of the above described exemplary embodiments, but 

associated with operations 410 and 506 shown in FIGS. 4 should be defined only in accordance with the following 

and 5, respectively, when the calendar select icon 128 is claims and their equivalents, 

selected. Upon such selection, a window 701 is displayed What is claimed is: 

which identifies each of the calendars. Note FIGS. 9C and 1- A portable data storage module for simultaneously 

9D. As indicated in decision 700 and operation 702, a user 50 depicting multiple calendars on a single display comprising: 

may select among the calendars by toggling through the a portable, hand-held housing including a top face, a 

identifiers and using the check boxes 703 of the window. bottom face, and a side wall therebetween for defining 

Thereafter, the calendars may be edited, added, or moved in an interior space; 

operations 704 using a new button 706, edit button 708, and an input device situated on the top face of the housing and 

a pair of arrow buttons 710. 65 adapted for allowing input of data; 

Finally, FIG. 8 is a more detailed flowchart delineating the a display situated on the top face of the housing and 

method associated with operation 412 shown in FIG. 4 when adapted for depicting data; 
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memory situated in Ibe interior space of the housing for 
storing a plurality of calendars each including a plu- 
rality of scheduled matters; and 

a controller situated in the interior space of the bousing 
and connected between the input device, the display, 
and the memory, the controller suitable for simulta- 
neously depicting a plurality of the calendars on the 
display. 

2. Hie portable data storage module as recited in claim 1, 
wherein the scheduled matters are depicted on the display 
with each calendar. 

3. The portable data storage module as recited in claim 1, 
wherein the calendars are divided into increments of hours. 

4. The portable data storage module as recited in claim 1, 
wherein the calendars are divided into increments of days. 

5. The portable data storage module as recited in claim 1, 
wherein the calendars are divided into increments of weeks. 

6. The portable data storage module as recited in claim 1, 
wherein the controller is suitable for manipulating the cal- 
endars. 

7. A method for controlling the presentation of at least one 
calendar on a display of a portable data storage module 
comprising the operations of: 

storing various calendars within a portable data storage 
module in separate databases, 

depicting at least one calendar on a display of a portable 
data storage module, the display situated on a top face 
of the portable data storage module; 

depicting a plurality of icons each corresponding to 
increments of time selected from the group of incre- 
ments of time including hours, days, and weeks; 

allowing the selection of one of the icons; and 

dividing the at least one calendar into increments of time 
corresponding to one of the icons that is selected. 

8. The method as recited in claim 7, and further compris- 
ing the operation of: 

altering one of the icons upon a plurality of calendars 
being displayed simultaneously. 

9. The method as recited in claim 8, wherein the selected 
icon is altered upon a plurality of the calendars being 
displayed simultaneously. 

10. The method as recited in claim 9, wherein the selected 
icon is altered as a function of a number of the calendars 
being displayed simultaneously. 

11. A method for controlling the presentation of a plurality 
of calendars on a display of a portable data storage module 
comprising the operations of: 

storing various calendars within a portable data storage 
module in separate databases; 

providing a window on a display of a portable data storage 
module which identifies each of the calendars, the 
display situated on a top face of the portable data 
storage module; 

allowing the selection of the identified calendars dis- 
played in the window; and 

simultaneously displaying all of the selected calendars. 

12. The method as recited in claim 11, wherein upon a 
plurality of calendars being selected, each of the selected 
calendars are depicted simultaneously. 

13. The method as recited in claim 12, wherein upon a 
plurality of calendars being selected, one of the selected 
calendars may be replaced with another calendar. 

14. Hie method as recited in claim 11, wherein the 
selection of the calendars is executed using check boxes. 



15. The method as recited in claim U, wherein the 
window is enabled upon selecting an icon. 

16. The method as recited in claim 11, wherein the 
window is a pull -down window. 

17. The method as recited in claim 11, wherein each 
calendar that is selected is given a calendar heading. 

18. A method for controlling the presentation of a plurality 
of calendars on a display of a portable data storage module 
comprising the operations of: 

storing various calendars within a portable data storage 

module in separate databases; 
depicting a plurality of calendars simultaneously on a 
display of a portable data storage module, the display 
situated on a top face of the portable data storage 
module, wherein each calendar is divided into sections 
corresponding to increments of time and scheduled 
matters are depicted in the sections; and 
altering a size of the sections as a function of a number of 
the calendars simultaneously depicted. 

19. The method as recited in claim 18, wherein the size of 
the sections is inversely proportional to the number of 
calendars simultaneously depicted. 

20. A method for controlling the presentation of a plurality 
of calendars on a display of a portable data storage module 
comprising the operations of: 

storing various calendars within a portable data storage 

module in separate databases; 
depicting a plurality of calendars with scheduled matters 
on a display of a portable data storage module, the 
display situated on a top face of the portable data 
storage module; and 
allowing movement of the scheduled matter of one of the 
calendars to another one of the calendars. 

21. The method as recited in claim 20, wherein scheduled 
matter is moved by dragging the scheduled matter on the 
display between the calendars. 

22. A method for simultaneously depicting multiple cal- 
endars on a display of a portable data storage module 
comprising the operations of: 

providing a plurality of calendar databases each including 

a calendar having a plurality of scheduled matters; 
providing a common database including a plurality of 
identification data sets each corresponding to the cal- 
endar of one of the calendar databases, the identifica- 
tion data sets each including attributes corresponding to 
the calendar database; and 
displaying the calendars of the calendar databases on a top 
face of the portable data storage module in accordance 
with the attributes. 

23. The method as recited in claim 22, wherein one of the 
attributes indicates that one of the calendars is selected. 

24. The method as recited in claim 22, wherein one of the 
55 attributes indicates that one of the calendars is a primary 

calendar. 

25. The method as recited in claim 22, wherein one of the 
attributes indicates that one of the calendars is read only. 

26. The method as recited in claim 22, wherein one of the 
60 attributes indicates that one of the calendars is a foreign 

calendar. 

27. The method as recited in claim 22, and further 
comprising the operation of: 

manipulating the calendars of the calendar databases. 
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MULTI-LAYERED ONLINE CALENDARING such as Microsoft Outlook, from Microsoft Corporation, 

AND PURCHASING provide this type of functionality. However, such applica- 
tions do not generally provide the ability to import event 

BACKGROUND OF THE INVENTION information from outside sources on a category-by^category 

i c- i j r .l i 5 Das is» and then to select individual events from selected 

1. Field of the Invention categories for inclusion in a user's personal calendar. 

The present invention relates generally to software for Furthermore, such applications do not provide a multi- 
generating and manipulating computer-implemented plan- layered calendaring system wherein events belonging to 
ning calendars, and more particularly to a system and different categories and selected by a user can be overlaid on 
method of multi-layered online calendaring and purchasing. 10 one another in a single integrated calendar. 

2. Description of Background Art Relatively recently, hosted calendaring applications have 
« . , .. r * • • . been developed which store, in a central location, all cal- 
Omyenbonal software apphcations for cdendanng and cndaring irf ormation for a ^ e of Such prior 

scheduling generally take one of two forms: stand-alone or art syst ems include, for example, appoint net 

networked. In a stand-alone calendaring application, some (www.appoint.netX Yahoo! Calendar (calendar.yahoo.com), 

sort of user interface is provided which allows a user to 15 and EventCenter from Amplitude Software Corp. 

specify dates and times for events. Events may then be (www.amplitude.com). Users access their calendar informa- 

viewed on a day-by-day, week-by-week, or month-by- tion across a network, such as the Internet, and security is 

month basis, depending on the user's wishes. In many such assured by requiring that each user provide a login and 

applications, selective viewing of certain predefined catego- password when accessing the system, 

ries of events is provided. 20 Some of these hosted calendaring systems allow users to 

An example of a stand-alone calendaring application is add events from outside sources to their personal calendars, 

"In Control" by Attain Corporation. Many other calendaring if desired. In general, however ever, such capability is 

applications are available which offer similar features. In "In limited in its flexibility. In particular, none of these calen- 

Contror, three views of the user's calendar information are daring systems allow a user to select a category of events, 

available: Outline, Calendar, and Day. Outline View allows 25 and subsequently add individual events from the category to 

the user to view events in a list format, and also permits a personal calendar. Furthermore, none of these systems 

hierarchical arrangement of the event descriptions. A date provide a multi-layered calendaring system wherein events 

and tune can be associated with each event, and the user can belonging to different categories and selected by a user can 

also specify other types of information, such as priority, be overlaid on one another in a single integrated calendar, 

description, and the like. In Calendar View, a conventional 30 What is needed is a calendaring application that allows a 

calendar is displayed. Events from the Outline View are higher level of flexibility in the way events can be imported 

shown on the calendar in their appropriate locations accord- and viewed. 

ing to the date associated with each event. The user can What is further needed is a calendaring application that 

specify the range of dates to be displayed, such as for permits a user to select categories of events that arc of 

example one week, two weeks, or one month. In Day Mew, 35 interest, and which provides features allowing a user to add 

events for a single day are shown on a display resembling a selected events from those categories to his or her personal 

conventional paper day-planner. Items having a specific time calendar. 

are shown within the daily schedule at the appropriate time. What is further needed is a calendaring application that 

Events not having a specific time are listed in a "To-Do" list allows a user to associate layers with certain subsets of 

next to the scheduled events. 40 events, and to selectively view any desired combination of 

Stand-alone calendaring applications, such as "In layers in an integrated manner on a personal calendar page. 

Control", are effective for managing one's calendar, but they What is further needed is a calendaring application that 

do not provide an easy mechanism for importing events allows a user to share selected calendar information, inchid- 

from an outside source in an automated manner. For selected events, with other users, 

example, if a user is planning to attend a baseball game at 45 What is further needed is a calendaring application that 

7:30 p.m. on Thursday, the entry for the baseball game must allows a user to purchase products, services, or tickets 

be manually entered in the calendaring application. Such associated with an event, using on-line communication 

applications do not provide an easy way to automatically means. 

import such information from, for example, a list of sporting 5Q SUMMARY OF THE INVENTION 

events from an outside source. The following disadvantages T , 

present themselves: . In accordance with the present invention, there is pro- 

w . vided a multi-layered online calendaring and purchasing 

Manual entry ot events is prone to errors; system and method which allows a user to specify categories 

If the scheduled event changes, the user may not be aware Q f events, to view events belonging to the specified catego- 

of the change and may fail to reflect it in the calendar; 55 ries from outside sources, and to add selected events from 

am * the outside sources to a personal calendar. The user can 

The above-described method does not provide a way to choose which categories of selected events are to be 

inform the user of events that may be of possible displayed, in any combination be or she desires. The user's 

interest personal calendar can also be shared with other users, or 

In addition, stand-alone applications do not provide the 60 selected events and/or categories can be shared, as desired, 

capability of sharing one's calendar information with other The user can set up a group calendar, specifying the mem- 

users, bers in the group, where every group member can access the 

Some prior art calendaring applications operate in a calendar and make changes to it Different levels of access 

networked environment and thereby aUow sharing of cal- can be specified for different members of the group. The user 

endar information. Individuals' calendar information can be 65 can also import events from other users' calendars. In 

shared across a network connection (if the owner of the addition, purchases of products, services, or tickets can be 

information grants permission for such access). Applications effected using links associated with displayed events. 
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A user logs onto the calendaring system by providing a FIG. IB is a block diagram of the services implemented 

unique login name and password that identifies the user and in one embodiment of an application server according to the 

allows the system to retrieve that user's personal calendar present invention. 

and associated information. In one embodiment, as FIG. 2 is a block diagram of an embodiment of a client 

described below, the calendaring system is hosted on a 5 computer for practicing the present invention, 

server that is connected to the Internet, and the user logs in FIG. 3 is a functional block diagram of a block diagram 

by interacting with the server via a web page. Q f the functional components of the user interface of the 

Once the user has logged in, he or she can enter any of present invention, 

several different areas of the system, in order to perform pic. 4 is a screen shot of a login page, 

different types of activities. An Event Directory allows the 10 _ _ . . . f 

user to seleV categories of events that are of interest. An FIG. 5 is a screen shot of a What s New page. 

Event Tracker allows the user to view events associated with RG 6 B a screen shot of an Event Directory page, 

selected categories, to obtain more details co Deeming such FIGS. 7A and 7B are screen shots of an example of an 

events, and to selectively add events to the user's personal event schedule in month view. 

calendar. A My Calendar area provides several views of the 15 FIG. 8 is a screen shot of a Month View of a Favorite 

user's personal calendar, including events that were selected Events screen. 

using the Event Tracker, as well as events that have been pic. 9 is a screen shot of a Week View of a Favorite 

manually added by the user. In the My Calendar area, the Events screen. 

user is able to view and manipulate any of these events. p, G 10 b a smea sbot of a Day View of a Favorite 

Finally, a What's New area is available for alerting the user 20 Events screen 

to new categories and events tfiat may be of interest; this ^ u ^ a ^ ^ of , „ ^ of , M Calcndar 

area may also be used to emphasize particularly important 
events. 

„ ' n . . . . FIG. 12 is a screen shot of a Week View of a My Calendar 

The Event Directory provides listings of event categories, screen 

preferably arranged by area of interest. Event categories 25 ^ " ^ . , , ^ 

• , j r % ' *j* FIG. 13 is a screen shot of a Month View of a Mv 

include, for example, movie opening dates, sporting events, «h 

computer tradeshows, and the like. Users can develop their Calendar screen. 

own event categories and share them with other users by nG 14 is a screen shot showing a My Calendar detail 

publishing them on the Event Directory. The user can click screen. 

on any event category and view a list of events belonging to 30 FIG. 15 is a block diagram showing the collection of 

that category. Additional information can be obtained for events data according to the present invention, 

each of the events. The user can choose to select any event FIG. 16 is a flowchart showing basic operation of a 

categories for inclusion in the Event Tracker. The user can default Execute method. 

also select a "localized" option which restricts events to fig. 17 is a flowchart showing a user authentication 

those located in the user's city, state or other region. process. 

The Event Tracker displays a list of events belonging to fig. 18 is a block diagram of the operation of a template 

the selected categories. The user can select from several processor to generate an HTML file, 

different views of the displayed events and can also choose* piG. 19 is a diagram showing a document template having 

to view one category at a time, or all categories at once. ^ several parts. 

Events can be sorted by date or by category, as desired Tbe p, G 20 fe a ^ & q[ ^ tion rf a 

user can click on a button to add a particular event to Ins or ^ rocessor to rale m HTML file, 

her personal calendar. In addition, the user can click on a ' , . m , , _ 

button for online ordering and purchasing of products, 21 is a block diagram of a calendar service according 

services, or tickets as appropriate for the particular event. to one embodiment of the present invention. 

The My Calendar area provides an extremely flexible and U RG 22 * * bl °f k showin S ™ exam P le of *■ 

configurable personal calendar. The user can choose from ***** 0WDershl P kerarchy. 

daily, weekly, or monthly views, and can select particular DETAILED DESCRIPTION OF THE 

categories of events to be displayed, or can choose to see all PREFERRED EMBODIMENTS 

events. Thus, the system provides a multi-layered calendar, 50 System Architecture 

where each layer corresponds to an event category, dewing Referring now to FIG. 1, there is shown a block diagram 
multiple categories simultaneously provides an integrated Q f the system architecture of an embodiment of the present 
,. personal calendar snowing all events in one place. The user invention. System 100 is implementedin a networked corn- 
can add appointments and other events manually in the My puting environment. Individual elements communicate with 
Calendar area, and such events are displayed alongside S5 one another using standard protocols such as, for example, 
events that were selected in the Event Tracker. The user can Transfer Control Protocol/Internet Protocol (TCP/IP) and 
also specify that he or she would like to be notified when an Hypertext Transfer Protocol (HTTP), over a data commu- 
event is about to occur, either by e-mail or by some other nication line such as a Tl or 13 line. Other implementations 
communications means. Finally, the user can specify are also possible, and system 100 may even be implemented 
whether he or she would like to share the personal calendar ^ on a non-networked computer, if desired, 
with other users. Iq one embodiment, the present invention operates in a 
BRIEF DESCRIPTION OF THE DRAWINGS networked environment such as the Internet or an intranet, 

and pages are provided for user access and interaction via a 

FIG. 1 is a block diagram of the overall architecture of an browser over the World Wide Web 116, as is known in the 

embodiment of the present invention. 65 art 

FIG. 1A is a block diagram of an application server Director 101 connects an individual client computer (not 

according to the present invention. shown) to system 100. Director 101 handles the low-level 
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interaction with an individual client computer, and accepts ers 105 in web servers layer 102. In one embodiment, server 

input and output for transmission to and from web servers 106 is implemented as a set of shared libraries that are 

layer 102. in one embodiment, where several load balancers dynamically Linked and loaded at runtime. 

105 are provided within layer 102, director 101 selects the Application server 106 is capable of running a number of 
least loaded load balancer 105 for connection, so that the 5 processes 108 simultaneously. Upon initial connection by a 
load is relatively balanced among the components of web particular user, the user is assigned to a selected process 108, 
servers layer 102. Director 101 is also able to invoke a thread based on load balancing parameters. 

to determine if the user is a new or returning user, based on Each process 108 contains a number of simultaneously- 
either 1) the particular Uniform Resource Locator (URL) executing application threads 115. Application server pro- 
string used to connect to system 100; or 2) a "cookie" file 10 cesses 108 interact with user cache 109, which provides 
that has previously been stored on the user's machine. If the temporary storage of personal calendar information for 
user is a returning user, director 101 can call a What's New particular users. Such information may include, for example, 
page which retrieves personal calendar information from the user's selected settings and options, favorite events, and 
database servers layer 104 and presents relevant information other information. Cache 109 obtains information from 
to the user as appropriate. 15 personal calendar information database 112 as needed, and 

In one embodiment, director 101 is implemented using writes information to database 112 when appropriate. Cache 

Big IP, from F5 Labs, Inc., for connecting web servers layer 109 provides improved performance by obviating the need 

102 to the World Wide Web 116 in a multiplexed manner for for a direct connection between process 108 and database 

optimal load balancing. 112. In one embodiment, cache 109 for a particular user is 

Web servers layer 102 contains one or more load balanc- 20 released from memory when either some predetermined 

ers 105 for determining which application server 106 is best time period expires, or when memory is needed and that 

able to handle a particular connection for a particular user. user's data is the oldest cache 109 that has not yet expired. 
In one embodiment, load balancers 105 are implemented as Process 108 also interacts with event cache 110, which 

Sun Microsystems Ultra 5 servers running a load balancing provides temporary storage of event data taken from events 

client. New users are sent to the least-loaded application 25 database 114. 

server 106. Returning users are sent to the application server In one embodiment, process 108 remembers where a 

106 containing the process that serviced the user during the particular user's cache 109 is located, so that if the user 
most recent connection with that user. This technique advan- returns to the site (ix. re-establishes a connection) and his or 
tageously facilitates access to a previously stored user cache, her cache 109 is still available, process 108 is able to utilize 
which improves performance as will be described below in 30 the cache 109. 

connection with FIG. 1A. A long-term memory (LTM) 107 Referring now to FIG. IB, there is shown a block diagram 

provides a mechanism for storing information as to which of the services implemented in one embodiment of an 

process serviced the user in the past, so that this information application server 106 according to the present invention, 

can be retrieved by load balancers 105 upon the user's Application implementation 121 implements each page of 

return. 35 the user interface using templates and a component-driven 

Application servers layer 103 contains one or more appli- user interface implementation. Application implementation 
cation servers 106. Application servers layer 103 provides 121 also parses HTTP parameters and generates HTML 
an intermediate layer between database layer 104 and web output for pages. Utilities 122 include implementations for 
server layer 102. Application servers 106 run the software parsing and formatting functions, high-level calendar 
code for interacting with database layer 104 and for 40 operations, and e-mail notification services. Session man- 
retrieving, modifying, and storing data in databases 112 and agement 123 authenticates, tracks, and manages user ses- 
114. In one embodiment, each application server 106 is a sions for calendaring operations, and stores a cache of user 
Sun Microsystems Enterprise 450 server. and calendar data as needed to maintain sessions. Calendar 

Database servers layer 104 contains databases such as service 124 implements the core object model for accessing 

personal calendar information database 112, events database 45 user profiles, calendars, events, calendar links, and collec- 

114, and the like, for maintaining scheduling and other tions of objects. Service 124 also implements event lookup, 

information for users of the system, and also maintaining object caching, and persistence. Finally, service 124 serves 

information describing scheduled events and announce- both personal calendars and event directory data using a 

ments. In one implementation, individual databases within common object model. Other services 125 provide access to 

layer 104 are stored on separate database servers such as Sun 50 non-calendar-oriented data services such as weather, 

Microsystems Enterprise 4500 servers. Databases may be horoscope, and application configuration settings. The 

stored in parallel redundant fashion for backup purposes. operation of the relevant components of application server 

Personal Calendar Information database 112 contains vari- 106 to implement the present invention -will be described in 

ous types of data, including personal event data HI for more detail below, 

various users. Events database 114 can also connect with 55 Client Computer 

other data sources (not shown) as desired, so that informa- Referring now to FIG. 2, there is shown a block diagram 

tion describing events can be imported and made available of a client computer 200 that can be connected to system 100 

to users of system 100. for practicing the present invention. In one embodiment, 

In an alternative embodiment, each database in database client computer 200 is implemented on a personal computer 

servers layer 104 can be split into a plurality of smaller 60 running the Microsoft® Windows™ 95 operating system on 

databases, each for a subset of users. an Intel® Pentium® processor. The user interacts with the 

Referring now to FIG. 1A, there is shown a block diagram present invention by establishing a network connection with 

of an application server 106 according to one embodiment of director 101 over the World Wide Web 116 using a TCP/IP 

the present invention. Application server 106 serves per- connection and a browser application running on the afore - 

sonal calendars, event directory contents, user profiles, and 65 mentioned client computer 200. Thus, as the user operates 

other types of pages to users in response to Hypertext the present invention, he or she is presented with interactive 

Transfer Protocol (HTTP) requests relayed by load balanc- web pages that provide information and accept input, as is 
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known in the art One skilled in the art will recognize that 
other embodiments, including other types of software 
applications, processors, and operating systems, are also 
possible. 

In the block diagram of FIG. 2, client computer 200 is 
shown having a central processing unit (CPU) 201, display 
device 202, input device such as a pointing device 203, 
random access memory (RAM) 204, and storage device 205. 
Also provided is a connection 207 to a network such as the 
World Wide Web 116, in order to establish contact with 
system 100 of the present invention. The following detailed 
description of the invention will make reference to exem- 
plary implementations of such components, though other 
embodiments may also be used. For example, CPU 201 is a 
microprocessor such as an Intel Pentium processor; display 
device 202 is a conventional monitor or screen such as a 
cathode-ray tube (CRT); pointing device 203 is a mouse or 
trackball, though other input devices such as keyboards can 
also be used; RAM 204 is some quantity of conventional 
memory as is commonly supplied with personal computers; 
storage device 205 is a hard disk or similar device for 
long4erm storage of programs and data; and Internet con- 
nection 207 is implemented using known protocols such as 
TCP/IP across a modem, Tl or T3 line, or other connection 
medium. 

In a preferred embodiment, the user interacts with system 
100 using a browser application. Such browsers are well 
known in the art, including for example Netscape Navigator 
and Microsoft Internet Explorer. One skilled in the art will 
recognize that other embodiments of the invention, that may 
operate without use of a browser, are also possible. 

For purposes of this description, the terms "page" and 
"screen" are used interchangeably to refer to a user interface 
element presented to the user via the browser. 
User Interface and Application Operation 

Referring now to FIG. 3, there is shown a block diagram 
of the functional components of the user interface of the 
present invention. Each of the functional components shown 
in FIG. 3 will be described in more detail below, with 
reference to specific screen shots and other user interface 
elements. As will be seen below, each element in FIG. 3 may 
be implemented as a web page in an Internet-based appli- 
cation. The user can navigate among the various pages 
shown by clicking on links in hypertext documents, as is 
known in the art of browsing web pages. As will be shown 
in other Figures, one embodiment of the present invention 
uses a metaphor showing "tabs" for navigation among the 
pages. 

FIG. 3 also illustrates the overall task flow 300 of one 
embodiment of the present invention, with connections 
between elements representing hypertext links from one 
page to another. 

Home/login page 301 welcomes the user to the applica- 
tion or website, upon initial connection. The user may elect 
to login at .this point by providirjg-input specifying ^ login 
identifier and password. This allows system 100 to retrieve 
user-specific information, by reference to a record stored in 
database 104 of the system. 

If the user has not used the system before, he or she is 
prompted to sign up in 302, by selecting a login identifier 
and password for future reference. A new record is created 
and stored for the user. The user is also given the option of 
signing up in a group using the group sign-up page 304, 
which allows the user to share his or her calendar with other 
members of selected groups. Page 303 contains a description 
of groups and their operation. 

Once the new user has signed up using 302 and/or 304, a 
welcome page 305 is presented, confirming that the user's 
record has been stored in the system. 
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Once the user has been identified via user login 301, or 
signed up and welcomed (302, 304, and 306), a What's New 
page 306 is presented. As will be described in more detail 
below, What's New page 306 highlights important events 

5 and announcements that may be of interest to the user. New 
event calendars may also be presented in this screen. In 
addition, in one embodiment of the present invention 
wherein shared group calendars are employed, the What's 
New page 306 can inform users of changes to shared 

10 calendars. Finally, the system can display reminders of 
upcoming events which the user has previously selected 

Event Directory pages 317-319 provide a directory of 
event categories including Event Directory Contents 317 
containing an overall list of event categories, Event Cat- 

15 egory Home Pages 318, containing descriptions of each of 
the event categories, and Event Category Subdivisions 319, 
containing descriptions of subdivisions -within particular 
event categories. 

From any of pages 317-319, the user can view schedules 

20 of events belonging to a selected category or subdivision. 
Such event schedules can be viewed in several different 
formats, such as for example a Day View 320, a Week View 
in grid format 321, a Week 'View in list format 322, a Month 
View in grid format 323, and a Month View in list format 

25 324. Each of these views provide a display of a number of 
events belonging to a particular category or subdivision. The 
user can click on a particular event in any of views 320-324 
to see an Event Details page 325 showing details for the 
selected event. 

30 The user can select individual event categories and/or 
subdivisions for display in Favorite Events pages 313-315. 
Selecting an event category in this manner is referred to as 
"subscribing" to the event category. Favorite Events pages 
313-315 display selected events in either a Day View 313, 

35 a Week View 314, or a Month View 315. Pages 313-315 
allow a user to select individual events from the selected 
categories, to be added to the personal calendar. The user can 
also access an Edit Favorites page 316 which allows him or 
her to add or remove categories and/or subdivisions from 

40 display in favorite Events pages 313-315. 

My Calendar pages 307-310 provide access to the user's 
personal calendar. My Calendar pages 307-310 show an 
integrated, multi-layer overview of events from selected 
categories, as well as manually-entered events. Several 

45 displays are available, including a Day View 307, a Week 
View in list format 308, a Week View in grid format 309, and 
a Month View 310. Details on any appointment or event are 
available from the Details page 311. In one embodiment, 
system uses Event Details page 325 to show details of a 

50 selected event that was previously selected from the Event 
Directory, and Appointment Details page 311 to show details 
on manually-entered events and appointments. An Options 
page 312 is also provided, for configurings and selecting^ 
among various system options and preferences. Events and 

55 appointments can be added, modified, or deleted as desired. 
Help pages 326 are provided to assist the user in using the 
various components of the system. The user can retrieve a 
selected help page 326 by clicking on a "Help" link on any 
of the pages in the system. 

60 Referring now to FIG. 4, there is shown a screen shot of 
a Login page 301 according to one embodiment of the 
present invention. As with all pages discussed herein, Login 
page 301 is presented as an HTML page that may be 
displayed to the user on a conventional browser screen, 

65 though other embodiments may use different techniques for 
presenting user interface elements to the user. Login Name 
field 402 and password field 403 are provided for the user to 
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enter relevant information allowing tbe system to identify 
him or her. In response to tbe user entering tbe information, 
system 100 retrieves centrally stored user-specific informa- 
tion 111 from database 112, including user preferences and 
personalized calendar information. As described above, such 
information is retrieved from user cache 109 if available. 

Login page 301 also provides links to other pages, for 
initial sign-up 404, on-line help 407, event categories 406, 
and miscellaneous information about tbe service 405. 

Referring now to FIG. 5, there is shown a screen shot of 
a What's New page 306 according to one embodiment of the 
present invention. A personalized welcome greeting 501 is 
displayed, as well as any important announcements 502. Tbe 
information displayed in What's New page is taken from the 
user's individual records in database 112. 

In an alternative embodiment, the What's New page 
provides information -describing changes to shared 
calendars, new features, and other relevant information. 
Reminders of upcoming events which were previously 
selected by the user can be provided as well. 

Navigation bar 507 provides links to other pages in 
system 100, including My Calendar pages 307-310, Favor- 
ite Events pages 313-^315, and Event Directory pages 
317-319. Buttons 503 and 504 provide access to Event 
Directory pages 317-319 and My Calendar pages 307-310, 
respectively. links 505 provide access to a Group Calendar 
feature, as described in more detail. 

In one embodiment, a list of new event categories is 
provided (not shown). This list may include any categories 
that have been added to system 100 since the user last logged 
on, or it may be a list of new categories that are related to 
other categories to which the user has previously subscribed. 
Thus, system 100 is able to provide event category sugges- 
tions that are likely to be of interest to the user, based on his 
or her previous behavior. The user can select one or more 
event categories from the list. If desired, the user can obtain 
additional information on event categories. 

Page 306 shown in FIG. 5 is one example of a What's 
New page according to tbe present invention. Other con- 
figurations of the What's New page are also possible, 
without departing from the spirit or essential characteristics 
of the present invention. In particular, additional information 
can be provided on this page, such as announcements 
regarding changes to event categories to which the user has 
previously described. Also, the What's New page may be 
configurable, so that the user can select what kind of 
information is displayed there. 

Referring now to FIG. 6, there is shown a screen shot of 
an Event Directory Screen 317. Hyperlinks 601 to event 
categories are displayed, allowing the user to obtain more 
information, and if desired, "subscribe'* to that event cat- 
egory. Each hyperlink 601 links to an Event Category Home 
Page 318 providing de taileoVdescriptions ^of <vent catego- - 
ries. Each event category is a group of related events to 
which the user can subscribe, if desired. Event categories 
can include, for example, sports team schedules, movie 
release dates, schedules of conferences on a particular topic, 
meeting schedules related to a particular project or company, 
and the like. 

Event categories and related information describing indi- 
vidual events are provided to system 100 and stored in 
events database 114. Such information may be provided by 
external sources, such as online services listing scheduled 
events, as described below in connection with FIG. 15. 
Alternatively, such information may be manually entered in 
events database 114 by a system operator. In one embodi- 
ment of tbe present invention, individual users may provide 
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user-defined categories in the form of group calendars 
including scheduled events the user wishes to share with 
other users. For example, a project leader may create a 
personal calendar including meetings and deadlines related 

5 to the project, and then share that personal calendar as a 
group calendar. Other users involved with the project may 
then subscribe to the group calendar as an event category. If 
desired, security measures may be provided restricting 
access to a group calendar, so that only selected users can 

10 retrieve the information. 

In one embodiment, a search field (not shown) is provided 
to allow interactive searching of tbe event directory. 

Referring now to FIG. 15, there is shown a block diagram 
illustrating the collection of events data according to one 

is embodiment of the present invention. The process per- 
formed by tbe apparatus of FIG. 15 receives event feeds 
from content partners, processes the event'data, and stores 
them in event database 114. Information from database 114 
is cached into shared memory for access by application 

20 server processes as needed. The elements of FIG. 15 are 
implemented as a collection of programs and scripts for 
automated operation and import of event data. 

Loaders 1502 are software scripts resident in database 
servers layer 104 for extracting events data from external 

25 data sources 1501 such as web pages, publicly-accessible 
files and databases, and the like. In one embodiment, loaders 
1502 are configured to extract such data on a regular basis 
from a predefined set of sources 1501. For example, a loader 
1502 might be configured to run a File Transfer Protocol 

30 (FTP) operation to obtain data from a source 1501 at 9:30 
a.m. every Tuesday morning, then to run the obtained data 
through a formatter to create a Structured Query Language 
(SQL) file, and finally to run a script which loads the data 
from tbe SQL file into events database 114. Loaders 1502 

35 may obtain information from data sources 1501 by any 
conventional means, such as for example: FTP pull (FTP 
operation initiated by loader 1502); FTP push (FTP opera- 
tion initiated by data source 1501); web page push 
(Hypertext Transfer Protocol (HTTP) operation initiated by 

40 data source 1501); or Hypertext Markup Language (HTML) 
spider (automated traversal through a series of HTML pages 
on the World Wide Web). 

Once loaders 1502 have collected information from data 
sources 1501, the data is formatted and written to events 

45 database 114. Users 1503 may also provide user-published 
events 1504 manually, which are also added to events 
database 114. In addition, a group calendars database 1506 
may be provided for storing events information related to a 
particular predefined group of users. Users 1503 can con- 

50 tribute event information that they would like to share with 
other users 1503 in a particular group. Such event informa- 
tion is written to group calendar database 1506 and then 

^ transferred to events database- 114. ----- 

In one embodiment, application servers 106 read and 

55 operate on event data using an event cache 110 (see FIG. 1A) 
in order to provide improved performance. In order to 
facilitate such operation, a cache generation (GenCache) 
operation 1505 is provided. GenCache operation reads 
events database 114 on a regular basis (e.g. daily) and 

60 generates an Event Cache file 110A containing selected 
event data in a format that can be transferred to RAM. In 
general, it is preferable if Event Cache file 110A contains 
data that is likely to be accessed, so that such access can be 
achieved without resorting to additional reads from events 

65 database 114. Once Event Cache file U0A has been 
generated, it is written to event cache U0 in application 
server 106. Event cache 110 is RAM-resident in server 106 
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and is therefore capable of being accessed more efficiently Month View 315. Navigation bar 801 provides links to the 

than can events database 114. available views. Navigation bar 507 provides links to other 

Once event cache 110 is in place, individual processes 108 screens, as described elsewhere in this disclosure. Additional 

can access events data from cache U0 as needed. If a buttons are provided, including an Edit button SM which 

particular event datum is not present in cache 110, applica- 5 allows the user to change personal preferences, a Help 

tion server 106 initiates a read from events database 114 to button 805 for providing access to Help pages 326, and a 

obtain the needed information. Log Out button 806 which exits the system. 

Referring now to FIGS. 7A and 7B, there are shown A checkbox 904 is provided for each event 903. The user 

screen shots of the Event Schedule Month View in list can add an event 903 to his or her personal calendar by 

format 324 and in grid format 323. Screen shots 324 and 323 10 clicking on the associated check-box 904 and clicking on 

may be displayed, for example, when a user selects a burton 807. Other mechanisms may be provided for adding 

particular event category by clicking on one of the links 601 individual events, or groups of events to the user's personal 

in the Event Directory screen 317. In screen 324, the user calendar. The particular user interface configuration to be 

may click on grid button 703 to be transferred to screen 323. used may depend on the characteristics of the network on 

In screen 323, the user may click on list button 704 to be is which system 100 is implemented. 

transferred to screen 324. Buttons 70S allow the user to view Referring now to FIG. 9, there is shown a screen shot of 

other, time periods-besides the one being displayed. In one a Week View 314 of a Favorite Events screen 1 according to 

embodiment, the information displayed in screens 324 and one embodiment of the present invention. As with screen 

323 comes from events database 114, which in turn may be shot 315, the user can select individual events belonging to 

collected from external sources, as described above in 20 subscribed categories, for inclusion in his or her personal 

connection with FIG. 15. calendar. The week-long view of FIG. 9 shows one week's 

Events 706 belonging to the selected event category are worth of events in a columnar format, 

shown in list form in screen 324, or in grid form in screen Navigation bar 507 provides access to other screens of 

323. The user can obtain additional detail regarding any system 100. Buttons 802-806 provide the same functionality 

listed event 706 by clicking on the link associated with the 25 as described above in connection with FIG. 8; namely, these 

event 706. System 100 then displays an event detail page buttons allow the user to specify which event categories are 

(not shown) containing the additional detail. to be displayed (or overlaid on one another) in the Favorite 

The user can subscribe to the displayed event category by Events screen, and also provide Edit, Help, and Log Out 

clicking on Tracker button 702. Events from the event functions. Navigation bar 801 allows the user to navigate 

category will then appear on the Favorite Events screens 30 among Day View 313, Week View 314, and Month View 315 

313-315, as described below. In addition, in one embodi- of the Favorite Events screens. 

ment the user can add individual events to his or her personal In the Week View shown, each day of the week is 

calendar without subscribing to the event category, by displayed as a column 902. The user can click on the column 

clicking on a button within the event detail page (not header to see a Day View 313 for the selected day. Within 

shown), or on a button (not shown) on screen 324 or 323. 35 each column 902, events 903 are listed in a grid format by 

Referring now to FIG. 8, there is shown a screen shot of time of day, with a separate space provided for all-day 

a Month View 315 of a Favorite Events screen according to events. In an alternative embodiment, events 903 can be 

one embodiment of the present invention. Favorite Events listed using other formats, such as by category, or 

screen allows the user to view events from selected catego- alphabetically, for example. As in screen 315, the user can 

ries to which he or she has subscribed. The user can select 40 add events to his or her personal calendar by clicking on 

whether to view all events for a time period from subscribed check boxes 904 and button 807. 

categories, or to view events only from selected subscribed Referring now to FIG. 10, there is shown a Day View 313 

categories. Thus, the subscribed categories can be thought of of a Favorite Events screen. Operation of Day View 313 is 

as "layers" which can be placed on top of one another and similar to that of Month View 315 and Week View 313, 

viewed together, separately, or in any combination. This 45 described above. Day view 313 shows events associated 

layering concept extends to views of the user's personal with a particular selected day. 

calendar, as will be seen below. Buttons 802 specify indi- In Day View 313, events are divided by category, denoted 

vidual event categories for display, which the user can select by category headings 1001. Events 903 are displayed for 

in any combination desired. In one embodiment, buttons 802 each event category heading 1001. Buttons similar to but- 

are provided for each event category to which the user has 50 tons 802 in Month View 315 and Week View 313 may be 

previously subscribed. Screen 315 shows all events belong- provided, allowing selection and de-selection of particular 

ing to the selected event categories in the month being event categories for display. In one embodiment, an event 

.displayed. Update buUoni803 lakes the user to -the Event* - category is only listed if . it contains events within the- day 

Directory screens 317-319 (see above), where he or she can associated with the current display. In other words, in this 

subscribe or unsubscribe to event categories. 55 embodiment, if there are no Cultural Events occurring on the 

In one embodiment, the Favorite Events screen also day being displayed, the event category heading 1001 for 

contains event categories representing shared group calen- Cultural Events will be omitted from the display, 

dars of other users. Thus, users can create personal or In one embodiment, each event category heading 1001 

work-related group calendars which can be shared and button (not shown) providing a link to the Event Schedule 

subscribed to as are public calendars. Such group calendars 60 for the category. This link takes the user to a screen, similar 

are listed as additional buttons 802, allowing the user to to that shown in FIGS. 7A and 7B, listing events belonging 

select or de-select individual group calendars are view to the specified category. Underneath the heading 1001 is a 

associated events as desired, "layered" on top of other list of individual events 903 belonging to the category. For 

displayed events in screen 315. each event 903, a dale and description is provided, as 

In one embodiment of the Favorite Events screen, several 65 appropriate. If applicable, a time of day may also be shown, 

different views of events are available. For example, the user If appropriate and available, a link may be provided to a 

may select from a Day View 313, a Week View 314, or a more detailed description of the event. Finally, button 904 is 
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also provided for adding the eveot to Ihe user's personal outside source are Dot replicated, but rather a reference (or 

calendar. Thus, as described above, the user can select "pointer") to the event in database 114 is stored in the user's 

individual events belonging to subscribed categories, for personal records, allowing the invention to access the data 

incorporation into his or her personal calendar. This provides describing the event from the outside source. One advantage 

improved flexibility, in that the user need not add an entire 5 to the latter technique is that any subsequent updates to the 

calendar and thereby possibly add events which are not of event can automatically be reflected by the application when 

interest, but can tailor the personal calendar to bis or ber the user views the My Calendar screen, 

individual needs. In some embodiments, addition of all In one embodiment, the user can click on any event shown 

events in a category can also be provided without requiring in list 1110 or in the list of "all day** events 1111, to be 

individual selection of each event, by clicking on a button 10 presented with a screen showing more detail on the selected 

(not shown) associated with the category as a whole. event The user may also edit the event if desired, as 

In one embodiment of the present invention, each sub- described below in connection with FIG. 14. 

scribed category is color-coded, and individual events In another embodiment, a link may be provided for 

belonging to the category are tagged by a color flag match- making a purchase associated with a particular event. For 

ing the color of the category. Thus, in the example shown, 15 example, if the event is a concert, a link to an on-line 

the movie releases category may be associated with the color ticketing service maybe provided, for purchasing tickets to 

bhie, and all movie release events would then include a the concert. The link can be targeted to a particular event 

small bhie tag. One skilled in the art will recognize that other within an electronic commerce site that sells tickets, so that 

visual characteristics could be used to associate events with the user need not re-enter the particulars of the event in order 

categories, such as a distinctive icon, font, or other tech- 20 to purchase tickets. Alternatively, such an approach may be 

nique. used to register for an event such as a tradeshow, by 

Referring now to FIG. 11, there is shown a screen shot of providing a link to a web page allowing the user to enter 

a Day View of a My Calendar screen 307 according to one registration information, payment information, and the like, 

embodiment of the present invention. On this screen, the Where possible, certain fields of the web page may be 

user is able to view and manipulate his or her personal 25 pre-filled with default information based on a profile previ- 

calendar, containing events that have been previously ously entered by the user and stored in database 112. 

selected from subscribed categories, as well as events that Similar techniques can be used for on-line sale of books, 

have been manually added by the user. music, and the lie, in connection with calendared events 

Navigation bar 507 provides access to other screens of such as release dates. In one embodiment, the user may use 

system 100, as described above. Navigation bar 801 allows 30 the present invention to track birthdays, anniversaries, and 

the user to select among a Day View 307, Week View the like; the system may then remind the user of such an 

308-309, or Month View 310 of his or her personal calendar. event and provide the opportunity to buy cards, gifts, and the 

Date entry field 1104 allows the user to type in a date, and like, as well as provide direct links to electronic commerce 

by clicking the Go button 1105, go to the My Calendar pages and sites that are of interest in connection with the 

screen 307 for the indicated date. Options button 1106 takes 35 upcoming event The system of the present invention can 

the user to a screen (not shown) where preferences and thus facilitate on-line commerce related to events that are of 

personal options can be set Help button 805 is a link to Help particular interest to the user. 

pages 326, and Log Out button 806 exits the system. In one embodiment, a subscreen 1109 may be shown 

Add Appointment button 1101 allows a user to 'manually when selected by the user, displaying a list of Favorite 

add an event or appointment to the personal calendar, using 40 Events. Subscreen 1109 contains a section for each event 

a screen similar to that shown in FIG. 14, described below. category selected by the user. Individual events 1113 asso- 

In this way, the invention can be used as a tool for integrat- ciated with each event category, and belonging to the current 

ing personal events and appointments in a calendar with date, are displayed. The user can click a button 1114 to add 

selected events obtained from an outside source, by over- an event 1113 to the personal calendar for display on the My 

laying the two types of events as layers in a single calendar. 45 Calendar screen 307. 

In one embodiment, the user may also click on buttons 1102 In one embodiment, the user can select which categories 

to add an appointment at a particular time of day. of events are to be displayed in the My Calendar screen 307, 

In an alternative embodiment, My Calendar page 307 may so that he or she can view a subset of subscribed categories, 

also include a list of "to-do" and/or "all da/* items for the if desired. This provides a multi-Layering function, wherein 

day. These items generally do not have a specific time of day 50 each category can be considered a "layer** that can be viewed 

associated with them; rather, they are items that the user has in combination with other layers as selected by the user. The 

entered to remind him or her of tasks to be performed user can also select group calendars for display; events from 

~ sometime during the day. Tbe.user can add such -items using- - > ; - such calendars are shown in the My Calendar screen as an 

the Add Appointment button 1101, in much the same way as additional "layer**, if desired. 

appointments are added. 55 Referring now to FIG. 12, there is shown a screen shot of 

Also shown is a daily planner 1110 listing events and a Week View of a My Calendar screen 308 according to one 

appointments 1112 for various times throughout the day. embodiment of the present invention. Screen 308 operates in 

These events and appointments are obtained by reference to a similar manner as the Day View 307 described above in 

the user's personal records in database 112 reflecting a connection with FIG. 11. Events for a week-long period of 

manually entered item (such as a lunch appointment), or 60 time are shown, in list format 1202. Grid button 1205 

they may be descriptive of events obtained from events provides access to a screen (not shown) that displays the 

database 114 representing event data from an outside source week's events in a grid format, links 1203 provide access 

(such as, for example, a concert or movie). In one to individual Day Mew screens for each day in the week, 

embodiment, events selected by the user from an outside Buttons 1204 open a Favorite Events tracker subscreen 

source are replicated in the user's personal records in 65 similar to 1109 in FIG. 11, for displaying individual events 

database U2, so that he or she can freely modify them. In within categories. Events 1112 are shown as links, which 

another embodiment, events selected by the user from an when activated access a detail screen for each event Buttons 
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1101, 1102, 1106, 805, 806, and 1105, and field 1104 operate Referring now to FIG. 16, there is shown a flowchart of 

in a manner similar to the corresponding buttons in FIG. U. the basic operation of the Execute method. The method 

Referring now to FIG. 13, there is shown a screen shot of performs the following actions: 

a Month View of a My Calendar screen 310 according to one 1601: Calls the class's Init method. The default Init 

embodiment of the present invention. Screen 310 operates in 5 method provided by the base class handles user authen- 

a similar manner as the Day View 307 described above in ti cation 1601A, setup of sessions 1601B, and binding 

connection with FIG. 11. Events for a month-long period of 1601C of common resources needed by the class, 

time are shown, in grid format 1302. links 1203 provide 1602: Calls the class's DoExecute method. The DoExec- 

access to individual Day View screens 307 for each day in ute method performs the actual work and returns 

the month. Events 1112 are shown as links, which when 10 HTML data. The actual DoExecute method to be per- 

actrvated access a detail screen for each event. Buttons U01, formed ^ de tennined by the particular subclass being 

1106, 805, 806, and 1105 operate in a manner similar to the implemented, which typically overwrites the default 

corresponding buttons in FIG. U. DoExecute method. 

Referring now to FIG. 14, there is shown a screen shot t£M ^ „ 4 . , , .. . ™ , - . 

. & w „ . , J ' .. . . 1603: Calls the class s Finalize method. The default 

snowing a My Calendar detail screen 311, containing 15 ,. , , i^w* j j c w 

. , f \. . ... tTL . ' & Finalize method releases 1603 A session and default 
detailed information describing an event. This subscreen can 

be used for entering infonnation for a new event; or for * n^Execule method for a particular class generally 

makmg changes to .nformation for a previously entered overridesthe DoExecute method 1602, and performs 

event. It is accessed by clicking on an event 1112 in screens c c ,, . , 

307, 308, or 310. 20 0Be ° f m ° re ° f me f ° UoWmg lasks: 

Event description 1401 contains several fields for display- Paise Pf ***** mchlded m tbe request into members of 

ing and making changes to various pieces of information me class or tem P orar > r vanables > 35 needed 

concerning the event, such as a title 1402, date 1403, start Perform some action by calling lower level service Appli- 

time 1404, duration 1405, check box 1406 for all-day events, ^on Programming Interfaces (APIs); for example, 

and recurring event information 1408, 1409, and 1410. A 25 dala to a database. 

notes field 1407 is also provided for miscellaneous infor- Output a componentized HTML document This may be 

mation. Fields 1402 to 1410 are populated with information implemented, for example, by calling the template 

from database 112 for manually-entered appointments, or engine in conjunction with a Parts Map, as described in 

with information from database 112 or 114 for other events. more detail below, along with user interface "parts" and 

In alternative embodiments, other fields may also be 30 related helper classes to construct an HTML page, 

provided, such as a reminder field for gift-related events, and Th e base class provides general purpose Init 1601 and 

the like. The selection of particular additional fields to be Finalize 1603 methods for most classes. Classes that require 

provided may be customizable. login are automatically authenticated by the base class, 

In an alternative embodiment, screen 311 contains a link freeing them from having to implement authentication redi- 

to another page allowing the user to perform other activities 35 rect logic. The base class performs parameter checking to 

related to the scheduled appointment (such as an online provide security by detecting invalid requests. The base 

purchase relating to the item). class also performs logout operations when needed. In 

Once the information has been entered, edited, and/or addition, the base class provides several general-purpose 

verified, the user can click on the Save Appointment button methods for handling, for example, building of URLs for 

1411 to save the entered information and return to the My 40 redirection, saving temporary session data, and parsing 

Calendar screen. Alternatively, the user can click the Back simple parameters. 

button 1412 to cancel all changes made to the event and Referring now to FIG. 17, there is shown a flowchart of 

return to the My Calendar screen. Finally, the user can delete me uscr authentication process 1601A as handled by the 

the appointment by clicking button 1413. base class. Classes that do not require authentication may 

Application Implementation 45 circumvent this process by overriding a RequiresLogin 

Referring again to FIGS. 1 and IB, the operation of method to return FALSE, 

application server 106 to implement the application will now Two separate sessions are maintained for each user, in 

be described. Generally, application server 106 responds to connection with the authentication process of FIG. 17: 

requests relayed by web servers layer 102. Generally, such a long-term session, managed by the load balancer and 

requests are provided to server 106 in HTTP format In 50 assigned a session ID (this session is automatically 

response to such a request, server 106 optionally performs bound to future requests using browser cookies, as is 

some action (if appropriate) and returns an HTML page to known in the art); and 

■• the user. In one embodiment, HTTP requests are- relayed to ■ ■ - a' calendar session, managed by- a session manager*' 

a load balancer 105. Load balancer 105 dispatches the (created upon authentication with the calendar service, 

request to the appropriate process 108. 55 assigned the same ID as the long-term session). 

In one embodiment, each request is handled by a class in The base class first checks 1701 for an existing long-term 

an object-oriented language such as C++. Server 106 session. If none exists, one is created 1702. The base class 

inspects its registry to determine which class to invoke for then retrieves 1703 the Session Id and looks up 1704 a 

each request. The Uniform Resource Locators (URLs) calendar session having that ID. If a calendar session having 

requests to server 106 contain the name or identification of 60 the corresponding ID exists 1705, the user is authenticated 

the class that can handle the request. 1706 and the authentication is checked 1707 to see if it is 

To handle a request, server 106 creates an instance of the valid. If so, the user is allowed to proceed; he or she is 

appropriate class and invokes its "Execute" method. The redirected 1709 to his or her default calendar view and the 

parameters of the HTTP request are made available to the authentication process ends. If the authentication is invalid, 

class as a name-value pair list in the base class. The Execute 65 access is denied 1708. 

method parses the input parameters, performs actions, and If in 1705 no calendar session having the corresponding 

generates HTML output. ID exists, the base class checks 1710 for an "auto-login" 
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cookie on the user's machine. Auto-login allows users to 
return to the web site without having to login. The auto-login 
cookie contains the user's encrypted login name and pass- 
word. If the cookie exists, the base class retrieves 1711 the 
login information. If the cookie does not exist, the user is 5 
redirected 1712 to a login screen. In one embodiment, the 
base class saves the original URL that the user was trying to 
access. The user is then prompted 1713 to enter login 
information. 

Login information from the auto-login cookie or from the 1Q 
user's entry is checked 1714 for validity. If it is valid, the 
base class creates 1715 a calendar session for the user, and 
the user is allowed to proceed. If a URL was previously 
saved (in 1712) the user is redirected 1709 to that location; 
if not, the user is redirected 1709 to his or her default 
calendar. If in 1714 the login information is invalid, the user 15 
is denied access 1716. 

In addition, in one embodiment a user may be automati- 
cally logged out by the session manager if they remain idle 
for some predefined period of time, or when the server is 
heavily loaded. In this case, the user must login again when 20 
he or she returns. 

Referring now to FIG. 18, there is shown a block diagram 
of the operation of a template processor 1804 to generate an 
HTML file. This technique is used in one embodiment of 
application server 106, with the template processor operat- 25 
ing as part of a process 108 to generate output for presen- 
tation to the user. Template source file 1801 contains HTML 
and process tags. Processor 1804 uses process tags to 
determine what items in file 1801 need to be replaced with 
dynamic data. 30 

Template map object instance 1802 is used by processor 
1801 to implement simple replacement of identifiers in 
source file 1801. Map 1802 contains a list of name-value 
pairs. For each process tag in file 1801, processor 1804 
consults map 1802 for the name specified in the tag. If the 35 
name is found, the value associated with the name is inserted 
in place of the process tag. 

Template data object instance 1803 is used by processor 
1804 to fill in data elements in a template file. For example, 
object instance 1803 may contain a list of items with 40 
attributes, such as events, calendars, and the like. Processor 
1804 uses object instance 1803 to iterate through a set of 
data, replacing process tags with the attributes of the ele- 
ments. 

Thus, to process a template source file 1801, processor 45 
1804 scans through file 1801 for process tags. When it finds 
such a tag it requests values from template map object 
instance 1802 and template data object instance 1803. These 
values are used to replace the process tags. Processor 1804 
also uses template data object instance 1803 to iterate over 50 
data sets referenced by process tags. 

For example, consider a source file 1801 containing the 
"following sc^irce: ' " * *"' T — 



<proccas typ^Kxll id-UscrNamc>RcplnccMc</proce3S> 
<process type-tik id^vents> 

<procesa type-cdl id-<vents.tiile> Event 
TiUc</proccE3> 

<process type-cdl 60 
id-events.<fale>12/31fl999</process> 
</process> 



Processor 1804 would scan through the file and first find 
the UserName cell tag. The type cell indicates that a simple 65 
replacement should be done, with data from either the 
template map 1802 or the template data object 1803. Tern- 
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plate map 1802 is checked first for a UserName element. If 
no value is found there, template data object 1803 is 
checked. If a value is found, the text "ReplaceMe" is 
replaced with the value. If no value is found the text 
"Rep lace Me" remains intact. 

Processor 1804 would then find the process tag with the 
keyword events. The type tile indicates that processor 1804 
should loop over a data set contained in template data object 
1803. The keyword events identifies which data set to use. 
Processor 1804 calls the following methods of the template 
data object 1803: 

IsEmpty: Determines if the data set events is present in 
template data object 1803; 

MoveNext Moves to each element in the events data set, 
returns FALSE when there are no more elements; 

GetVahie: Retrieves individual attributes from the current 
data element in events. 

Thus, in the example given above, processor 1804 would 
call MoveNext for as many events included in the events 
data seL Processor 1804 would then call GetVahie to obtain 
the events, title and the events, date attributes for each 
element in the data set. 

Once processor 1804 has processed all of the process tags 
in source file 1801, it generates an HTML file 1805 which 
can be passed to the user and read by a browser. 

Operation of processor 1804 will now be described in 
more detail. Referring now to FIG. 19, there is shown an 
example of a document template 1900 containing several 
parts, including header part 1901, tabs part 1902, navigation 
part 1903, day grid part 1904, event tracker part 1905, and 
footer part 1906. Parts 1901-1906 are modular user inter- 
face components used to implement and generate the various 
pages for the present invention. Thus, an HTML document 
is modularized into parts that can each be generated by a 
distinct class 2001 run by application server 106. 

Referring also to FIG. 20, there is shown a block diagram 
of the detailed operation of template processor 1804 to 
generate HTML output 1805. 

To implement the component model exemplified by docu- 
ment template 1900, two levels of template evaluation are 
used: 

Document-level template evaluation (controlled by the 
class) specifies which user interface components (parts) 
are included in a particular document, and how they are 
to be laid out A document-level template 1900 is used 
for this purpose. In addition, the template may include 
some common formatting and style elements. 
Part-level template evaluation (controlled by the parts 
within a document) is used to evaluate each part in the 
document by consulting a part template file 2006. The 
HTML data 1805 is then generated for that part's 
. particulars area in the document. ._ ; ; _ 

For each document, a single document-level template 
evaluation is performed, and any number of part-level 
template evaluations are performed. 

In the document-level template 1900, custom process tags 
are employed to specify parts to be included in the docu- 
ment. For example, the following example contains three 
parts: 

<process type-whenHeader title-"My Calendar Day 

View">Replace Text</process> 
<process type-whenTab template- 

myCalendarTab.html>Default Text</process> 
<process type-whenFooter>Replace Text</process> 
Part map 2002 translates each part tag into a section of 

HTML. Part map 2002 is passed by classes 2001 to 
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template engine 2005 when document-level template 2001 may implement MoveNext0 by incrementing an 

evaluation takes place. Parts map 2002 acts as a internal counter or by advancing the position of an 

dispatcher, interpreting custom tags and supplying event list obtained from the Calendar Engine, 

needed parts classes from parts library 2003. When Override the GetValueO method to return values for each 
engine 2005 requests that parts map 2002 translate a 5 attribute of the current data element This may include 
custom tag, map 2002 dispatches control to an instance accessing methods of calendar engine objects, format- 

of the appropriate part class from parts library 2009 by ting them, and returning them in a buffer. GetValueO is 

calling its Output method. also used to show or hide areas in a template. By 

The Output method of each part generates the HTML that returning a null string, GetValueO can effectively hide 

represents its user interface component in the document 10 a section of the template. This may be used to imple- 
Template engine 2005 replaces the custom process tag with ment conditional template evaluation, 

the HTML data generated by the Output method. Most parts Classes 2001 and Parts 2002 access the data they require 
use the template engine 2005 to create their HTML output, prior to starting template evaluation. Generally, such data 
in order to implement part-level template evaluation. The includes lists of events obtained from calendars. Other types 
part-level evaluations actually cause re-entrance of template is of data that may be required include, for example, user 
engine 2005 since the part evaluates its template 2006 profiles, calendar attributes, lists of tracked calendars, 
during a callback from document-level template processing. weather information, and 1 the like. The calendar service 
Template class 2001 contains the IsEmptyO, MoveNextO, serves up most of the data required by the user interface 
and GetValueO methods described earlier. presentation logic. 

Thus, for example, in implementing a calendar-oriented 20 Session Management 
parts, the following elements are employed: As described above in connection with FIG, IB, applica- 

Part template file 2006: contains the HTML and process tioa implementation element 121 includes session man age- 
tags for creating the part output ment 123 which authenticates, tracks, and manages user 
Part class implementation in template class 2001: A C++ sessions for calendaring operations, and stores a cache of 
class that implements the Output method. This class 25 user and calendar data as needed to maintain sessions. The 
embodies the presentation logic of the part, and may of session management 123 will now be described 
defer to helper classes for core presentation algorithms. m ™°/ e f etaiL m 
The template class 2001 may perform any of the Referring again to FIGS. 1A and IB, when a user is 
following, for example: authenticated, a session is created, as is known in the art of 

, , . . , , £, » 30 web application development. The session exists until either 

Establishing references to the cache of user data from the A , . ... . , , 

B ^ wu*< uma u^iii uiKr me user j QUt or ^ gggg^n expires. In one embodiment 

session manager. . , . r . . „ , 

& a session expires when the user remains idle for a certain 

Establishing a context object for communicating with the time period as specified in system configuration files, 

calendar engine. Sessions serve two primary purposes: 1) they obviate the 

Finding the data needed during template evaluation 35 need for reauthentication of the user with each web page 

(including, for example, accessing the calendar engine access; and 2) they facilitate the use of a cache to store data 

to obtain lists of events for all the days being (such as calendar data) in order to avoid unnecessarily 

displayed). retrieving the same data repeatedly from databases 112 or 

Parsing input parameters received with the HTTP request 114. In one embodiment, only one thread 115 of a process 

into arguments used during template evaluation (such 40 1W may access a session object at any given time. Other 

as, for example, start date, end date, calendar ID, event requests to access a session object are blocked until the 

IDs, and the like). thread 115 that is currently accessing the object is done. Ibis 

Optionally creating a Template Map class and populating Henrique me amoUDt of ***** checks needed 

it with name-value pairs used for replacement during to as j Jurc data integrity. 

template evaluation 45 ^ rncn a uscr logs on and a session commences, certain 

, , . , . 1AA . . . . information may be p re-fetched from database 112 and 

m^Tt™.^^ to uier ca<L 109, so that subsequent access to 

nle name, template map, and custom template data , . . - . „, r 1 . „ , 

obiect this data will be faster. The pre-fetching occurs immediately 

The template class 2001 objects may perform any of the <n "g? ^^rably prior tojtewmxx^ im i* 
following for example- 50 ber calendar. The pre-fetching need not be complete for the 

„ . f ' . r user to access his or her calendar. 

Provide convenient constructors for evaluation by the Periodically, session management 123 prunes the list of 
part : Jhe constnictor.acCepts arguments needed during ^ MaAm by removing sessions mat have been idle-fof 
template evaluation. The constructor may also validate loDger ^ a specified timeout period, specified in pre- 
data and transform it into a more usable form. 55 defined configuration information. In addition, in periods of 

Override the IsEmptyO method for the data set that the high load session management 123 may remove a session 
template data serves. A single template data class object before the time-out period is reached, as further specified in 
may serve more than one data set. For example, the Day the configuration information. A user attempting to access 
Grid part's Template Data class serves two data sets: a the system after his or her session has been removed must 
collection of all^day events and a collection time inter- logon once again to re-establish a session, 
vals. IsEmptyO ^ called by template engine 2005 when Calendar Service 124 

it begins processing a data set. IsEmptyO determines As described above in connection with FIG. IB, applica- 
whether there is any data in the set, and if so, position uon server 106 includes calendar service 124 which: imple- 
itself to point to the first element in the data set ments the core object model for accessing user profiles, 

Override the MoveNextO method to move to the next 65 calendars, events, calendar links, and collections of objects; 
available element in the data set If there are no more implements event lookup, object caching, and persistence; 
elements, MoveNextO returns FALSE. Template class and serves both personal calendars and event directory data 
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using a common object model. The operation of calendar 
service 124 to implement the present invention will now be 
described in more detail. 

Referring now to FIG. 21, there is shown a block diagram 
of calendar service 124 according to one embodiment of the 
present invention. Calendar service interface 2101 demies 
the contract between calendar service 124 and the applica- 
tion servers layer 103 of system 100, or of any other client 
of service 124. Core calendar engine 2102 implements the 
core algorithms and logic of the calendar engine. Data 
access layer 2103 provides the persistence behavior of all 
objects in calendar service 124. It implements access to both 
relational data 2104 (user data) and memory resident data 
2105 (event directory). 

Calendar Service Interface 2101. Calendar service 124 
provides the programming interface for accessing objects. In 
one embodiment, these objects are the only interface to 
calendar service data that is available to application servers 
layer 103 or any other client of service 124. These objects 
include, for example: 

User Account: Contains a user's profile, personal 
calendar, referenced calendars, and display prefer- 
ences. The user account is the primary object stored in 
the cached session object 
Calendar: Provides the common interface to calendars of 
all types (both personal and event directory schedules). 
Calendars are containers for individual events, and they 
interact with Event List and Day List objects to provide 
access to the events they contain. 
Event: Provides a common interface to events of all types, 
including personal events, event directory events, and 
linked events. The same class is used to represent 
recurring and non-recurring events. 
Calendar link: Represents some relationship between a 
user and a calendar. For example, there may be a 
"tracking" relationship for the event tracker, as 
described above. A calendar link provides access to the 
underlying calendar object instance. 
Day Link: Provides a convenient collection of events 
partitioned by day. The day list contains a set of Event 
List object instances — one for each day within a certain 
date range. Can also be used as an iterator to traverse 
through the contained Event Lists one at a time. 
Event List: Provides a collection of events sorted in 
various ways (such as by date, title, and the like). Can 
also be used as an iterator to traverse through the 
contained events one at a time. 
Calendar List: Represents a collection of "linked" calen- 
dars. Contains a set of Calendar Link objects. Each 
Calendar Link points to a Calendar object instance. The 
Calendar List can be sorted by various means. 
Sponsor/Category/Partner Provides the interface to both 
sponsor and category information. A calendar can have 
an associated sponsor as welTas an associated category 
and an associated partner, if desired. 
Object Ownership Hierarchy 2200. Referring now to FIG. 
22, there is shown an example of an object ownership 
hierarchy 2200. Calendar service 124 provides a global 
calendar manager object 2201. Calendar manager object 
2201 is the starting point for accessing objects in calendar 
service 124. In one embodiment, all calendar service objects 
are indirectly created through calendar manager object 2201. 

Calendar service 124 employs an object ownership hier- 
archy to control the life cycles of objects. For example, event 
objects are owned by a single calendar object The calendar 
object acts as a container for each event, and also controls 
the access rights, modification, deletion, and creation of the 
event. 
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In FIG. 22, calendar manager 2201 serves up both user 
account objects 2202 and public calendar objects 2206 
(event directory). For user accounts, authentication is 
required before access to a user account is granted. This can 

5 occur either via user login or by creation of a new user 
account, as described previously. Once a user account object 
2202 has been crated, it is possible to access the user's 
personal calendar object 2204, tracked calendar links 2203, 
and personal profile through the user account object 2202 

jo instance. 

For public calendars, authentication is not required. Cal- 
endar manager 2201 searches for the desired calendar and 
returns an object instance that provides access to the calen- 
dar's events and attributes 2206 and 2207. 
!5 Access Control. Access to calendar service objects and 
methods is controlled in two ways: 

Explicit access checking: Certain- operations require that 
the caller's identity be explicitly compared with the 
access permissions of the object being requested. For 
20 example, calendar manager 2201 requires a valid login 
name and password before it will create a user account 
instance 2202. 
Implicit access: Access to some objects is controlled 
indirectly by relying on some previous explicit access 
25 check. For example, once access to a user account has 
been granted, the caller is free to access the contents of 
the associated personal calendar and calendar links 
without further access checks. This is implemented 
using session management, as described previously. 
30 Access control is implemented using a context object. 
Calendar manager 2201 creates context objects for callers of 
calendar service 124. Operations that require an explicit 
access check are defined to take a context parameter. The 
context identifies the user performing the operation and the 
35 access level of that user. Calendar objects check the context 
permissions against the operation being performed to ensure 
appropriate access. In this way, security leaks can be avoided 
even when the application code contains a programming 

bug. '!»;..,..-• 

40 Object Creation and Modification. Objects are created and 
modified by their owning parent object, according to the 
defined hierarchy. Internally, objects implement their own 
interfaces. 

Parent objects control the modification, deletion, and 

45 creation of objects they contain. This allows the parent to 
modify its internal structures when its contents change. 
Furthermore, the implementation class can be hidden from 
clients of calendar service 124, so that parent objects act as 
an object factory for objects they contain. 

50 Creating a new object involves two steps. First, the caller 
requests a new instance of an object type from the parent 
The parent creates a new modifiable object instance and 
returns it to the caller. The object' 4nstance'idoes 'not' yet " 
persist in the calendar service database. Second, the caller 

55 requests an "update" of the contained object from the parent. 
The object may be an existing object or a new object The 
caller implements the update by writing changes to the 
database and updating its internal structures. For example, 
when a calendar updates a recurring event, it may need to 

60 recreate the expanded event instances due to a change in the 
recurrence rule. 

When deleting an object, the caller merely asks the parent 
to delete the contained object. 

Releasing Objects. As described previously, parent 

65 objects provide the means to access instances of their 
contained objects. Parent objects also control the release of 
their contained objects. When a client of service 124 is 
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finished with a calendar service object, it notifies the parent, Time-zone translation of events; and 

which releases the object instance. Expansion of recurring event instances from recurrence 

This allows the implementation of calendar objects to be rules, 

hidden from clients, so that the constructors and destructors Interface and Implementation Classes. As described 

of object classes are restricted (protected). Thus, the parent 5 previously, calendar service interface 2101 defines a set of 

object can implement object memory and resource manage- classes that define the contract between application servers 

ment in any manner desired. layer 103 and calendar service 124. Core calendar engine 

Calendar Types and Domains. In one embodiment, cal- 2102 returas instances of these classes to the caller. 

endar service 124 provides a single interface class for In one embodiment, the unplemenUtion of these objects 

calendars. This interface class is used for both personal 10 ? achieved by ^^ai *™« 124 cfcfining a set of 

calendars and event directory schedules (public calendars) f^f 5 that cn *^ lh 5 ^emenUtion^Tbe 

4l _ ... . _,•«■ * n_ . j • . implementation classes are collectively referred to as toe CE 

even though they have different attributes and persistence . r . , A , . 4 - . J , . 

, , TfT j +<sa . , . 4 c Layer classes, while the interface classes are known as the 

models. Calendar service 124 provides the concept of a CI Layer classes. 

"domain- for any object in the system. This domain is used, Calendar Manager 2201. Calendar Manager 2201 is a 

for example to distinguish between personal and public is m3icd at service startup. It creates and 

calendars and events. manages user accounts, public calendars, partner objects, 

Accessing Calendar Contents: Calendar service 124 pro- ao ^ qq^xi objects. 

vides two types of access to events in calendars. Each access Many calendar service operations use a context parameter 

type has several variation* to support the needs of applica- to vaUdalc access rights of tbe caller. In one embodimenU 

tion servers layer 103. 20 a context object is employed to embody access information. 

The first type of event lookup serves a series of events in context ob ject includes, for example: 

a Day List. A Day List is a list of event lists. Each list The User ID of the person initiating tbe request (a User ID 

contains a set of events for a single day The Day ijst of ^ access) 

contains an event list for each day in its date range (for A w , „ . . . - / , 4 , . , 4 

. , c ,_. . j - . „ Access Mode: Provides information as to the access nehts 

example, a week of events would be sorted into seven event 25 ^ ^ usef °^ 

lists). The Day List lookup is convenient for displaying „ „ * , , , . . 

calendarnoriented views of events, since it is very easy to Reference to the template class making the request. 

detennine the number of events on any given day within the Reference to a database transaction object. 

date range. The Day list lookup interface is implemented by Contexts can be created as follows: 

a Day List object. Callers use a SetTlmeSpanO method to 30 CreateGuestContext returns a context object with guest 

generate the list of event lists from either a calendar or a list access rights. The guest rights are not associated with 

of calendars. any particular user. 

The second type of event lookup serves events for a LoginNewUser creates a context object as part of new 

specified date range in one contiguous event list object. The account creation. Tbe context has the access rights of 

Event List lookup is used to display lists of events (such as 35 the new user account that is created, 

for pages 307 and 308) rather than calendar-oriented dis- LoginUser creates a context object as part of the login 

plays (such as pages 309 and 310). The Event List lookup process. The context object has the access rights of the 

interface is implemented by a Calendar class. Callers use a user account that is authenticated. 

GetEventUstO method' to obtain an aggregate event list. A context object can be used for any number of calendar 

Variations of GetEventUstO include: 40 service 124 operations. In one embodiment; state informa- 

Dale Range: Returns all events from a calendar within a tion is not maintained in the context Session management 

specified date range. 123 caches a context object in user session data for all 

Page Number: Returns a certain page of events starting calendar service operations during tbe life of the user 

from a specified date. A page is defined to be a certain session. 

number of events. For example, if the page size is 50, 45 Uscr Account Login and Registration. As described 

then page 2 would return an event list containing events previously, the LoginNewUser and LoginUser methods con- 

51 through 100 starting on the specified date. ^ ^ registration and login respectively. LoginNewUser 

Layered Calendar Views. Layered Calendar Views dis- creates a new user account implementation object 

play the contents of multiple calendars on a single calendar (CDUserAccount class), fills in the profile information, and 

display such as Views 307, 308, 309, or 310. Layered 50 ^ ycs mc account object to the user database. The account 

Calendar Views are implemented by calendar service 124 as 0 ^ect creates itself and a set of other objects associated with 

a Day List object that contains events . from multiple calen- * e user account (personal calendar object, calendar links 

dars. More specifically, me^vfeniTLists contained by the Day ' '"^ st )* ' ' " "* ' ' ^ 

List contain events from multiple calendars. Calendar manager 2201 provides access to the event 

The Day list class implements the Layered Calendar 55 directory calendars via the GetCalendar method. GetCalen- 

View. Callers use a SetTlmeSpanO method of the Day List dar lakes a calendar ID and returns a calendar object. In one 

and pass it a calendar list specifying all the calendars to be embodiment, event directory calendars are obtained from 

included in the display. calendar manager 2201, while personal calendars are 

Core Calendar Engine 2102. Core calendar engine 2102 accessed from a user account object, 

implements the core algorithms and logic of calendar service 60 To implement public calendar lookup, calendar manager 

124 including: 2201 creates an instance of a public calendar (class 

Object creation, deletion, and modification; ******** *J«* T^^^ul 

J . ID, and instructs the calendar object to load itself from the 
Control of object persistence operations; database. The CDPubhcCalendar class implements the data- 
Event lookup for day lists and event lists; ^ base lookup as described below. 

Object collections and sorting; On return from GetCalendar, the caller has a pointer to a 

Event caching; calendar interface object (class QCalendar). Typically, the 
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caller releases public calendar objects once the template 
class request has been processed. This is the case for Event 
Directory pages. However, Public Calendar instances are 
used to represent a user's tracked calendars. In this case, the 
Public Calendar instances are cached by the user account 
object— one for each tracked calendar. 

Calendar manager 2201 also serves partner objects. The 
partner object is a denormalized object containing informa- 
tion about categories and sponsors. Category/sponsor infor- 
mation is referenced by calendars in the event directory. 
Attributes of the category/sponsor are used in the various 
pages of the user interface (for example, sponsor name, logo, 
URL, and the like). 

At startup, calendar manager 2201 loads all partner 
objects from the database and caches them in memory. 
Calendar manager 2201 provides a single call to get a 
partner object by ID. Public calendars use this call to return 
their associated partner object 

User Account Implementation. In one embodiment, user 
accounts 2202 contain all information associated with a 
particular user within calendar service 124. User account 
2202 is the attachment point for all user data and is the 
primary object stored in the session cache 109. User account 
2202 provides access to the user's personal calendar, the 
linked calendars (favorite events), and the user's profile 
information. 

User account 2202 provides sole access to a user's 
personal calendar. Personal calendar object 2204 is created 
by user account 2202 at registration or login. Personal 
calendar 2204 has no attributes of its own and is therefore 
not actually stored in the database. Rather, personal calendar 
2204 is an instance of a calendar object that manages a set 
of events 

Calendar link 2209 defines a relationship between user 
account 2202 and a calendar. The relationship can have a 
type, such as a "tracked calendar" relationship. Calendar 
links 2203 can be used to denote other types of relationships 
between users and calendars as well. 

User account 2202 manages the set of all calendar links 
2203. It controls the creation, modification, and deletion of 
link objects, and controls their persistence operations, but in 
one embodiment does not implement them. When a user 
account 2202 is loaded, it performs a query for all calendar 
links 2203 and loads them into an internal list User account 
2202 provides an interface to obtain a copy of the list of 
calendar links 2203. The list can be sorted in any of a 
number of ways. Each list copy references the same object 
instances. 

The attributes of a user account 2202 fall into two 
categories: profile attributes and application settings- Profile 
attributes define the user's demographics and core account 
information. The user account 2202 provides methods to 
change profile attributes. These changes are made to a 
modifiable instance copy of the user account 2202 object, 
obtained from calendar manager 2201. Changes to profile 
attributes are saved immediately in the database. 

Application settings are fields that control the behavior 
and appearance of the application. These may include, for 
example: 

the order of events in the event tracker; 

the expand/collapse state of categories in the event 
tracker; and 

the minimize state of the event tracker. 

Some application settings are saved immediately when 
changed, while others are saved when the user's session 
expires through either explicit logout or session time-out. 

The user account implementation class provides a pro- 
tected method (FIushDeferred Changes) which calendar 
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manager 2201 uses to save application settings prior to 
deleting the user account object. Deferred write is used in 
order to minimize database accesses for common application 
customizations. 

5 Calendar Implementation. In one embodiment, calendar 
service 124 supports two types of calendars: 1) personal 
calendars, which contain user-specific private data loaded 
directly from database 112; and 2) public calendars, which 
represent schedules in the event directory database 114 

10 which are accessible by any user and whose data is refer- 
enced from the shared memory event cache 110. 

In one embodiment, the difference between the two types 
of calendars is the persistence mechanism used to inflate and 
deflate the calendar and event objects from the two domains. 

15 Before events are served up by the calendar, they are 
loaded into memory as a set of event object instances. 
Calendar service 124 maintains an internal event list col- 
lection object containing object instances for all event 
occurrences whose dates fall within the loaded date range, 

20 including each instance of a recurring event that falls within 
the loaded date range. The cached event instances are also 
translated to the calendar's target time zone and sorted by 
time. 

A calendar implementation class controls the loading and 

25 unloading of events over the loaded date range. The calendar 
implementation class implements a simple loading model 
which enforces a contiguous range for this date range. The 
maximum size of the date range is specified in server 
configuration files, for example as 50 days. The minimum 

30 load range size is also specified in server configuration files, 
for example as 10 days. The minimum load range size 
defines the "chunk" size for database queries. 

Cache 110 serves to optimize performance by minimising 
database accesses to personal calendar. Furthermore, cache 

35 100 pre-sorts events by date and time for the target time 
zone, as will be described below. 

Each calendar has the notion of a "zone focus." The zone 
focus is set by the client of calendar service 124 based on the 
time zone of the user's display. For event directory pages, 

40 the zone focus is set to the default time zone for the calendar 
being viewed. The zone focus for personal calendars is the 
user's time zone as specified in his or her profile. This is also 
true for "tracked" public calendars (calendars which are 
displayed with or over the personal calendar). 

45 When a calendar loads its events it also translates the 
events to its zone focus. This is done so that the calendar's 
internal event list can be presorted based on the target time 
zone. Event list sorting is done when the target time zone is 
known. All-day events do not shift across date boundaries as 

50 do events having a specific start time. Pre-sorting the inter- 
nal cache by date allows event lookups to be highly 
optimized, requiring no list duplication or sorting. 

Recurring Events. A pattern of recurring events can be 
stored in one database row in database 112 or 114. The 

55 individual occurrences of the recurring pattern need not be 
stored individually. Recurring patterns are stored in a table 
separately from non-recurring events. 

Calendar service 124 loads all recurring patterns from the 
database the first time the calendar is loaded. The recurring 

60 patterns are saved as event object instances in a separate 
internal recurring event list. When calendar service 124 
loads events, it also generates individual event instances 
from the list of recurring patterns. Thus, calendar service 
124 creates an event object instance for every occurrence of 

65 each recurring pattern whose date falls in the loaded date 
range. These recurring event instances are placed in the 
internal cache in the same manner as non-recurring events. 
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Each recurring event instance is assigned a unique ID 2. The computer-implemented method of claim 1, 

which is a combination of: 1) the event ID of the recurring wherein each of at least a subset of the events has a time, 

pattern from which the instance was generated; and 2) the 3. The computer-implemented method of claim 1, 

Julian date assigned to the recurring instance. The combined wherein the unique visual characteristic is a color. 

ID is used to uniquely identify recurring event instances by 5 4. The computer-implemented method of claim 1, further 

clients of calendar service 124. comprising: 

When the user modifies the pattern of a recurring event f) repeating steps a) through e); 

(for example, changes from repeat daily to repeat weekly), g) acC e ptirj g user input specifying a subset of the specified 

calendar service 124 performs the following steps: categories for display; and 

1) Delete all the existing recurring event instances asso- to h) displaying ^ computer-implemented personal calen- 
ciate with that patter from the internal cache; dar by overlaying information from the selected events 

2) Create new recurring event instances in the internal from the subset of the specified categories on a corn- 
cache based on the modified pattern; and mon display. 

3) Save the recurring pattern to the database. 5. The computer-implemented method of claim 1, further 
Furthermore, calendar service 124 is equipped to handle 15 comprising: 

a change from a recurring event to a non-recurring event, or d.l) accepting user input specifying a purchase associated 

vice versa. For example, if a user wishes to change a with the selected event; and 

recurring event to a non-recurring event, calendar service d.2) processing the specified purchase. 

124 performs the following steps: ^ 6. The computer-implemented method of claim 1, further 

1) Delete all recurring event instances associated with that comprising: 

pattern from the internal cache; f) displaying the computer-implemented personal calen- 

2) Delete the recurring pattern "master 7 * event from the dar. 

internal pattern cache; 7. The computer-implemented method of claim 1, further 

3) Delete the database row associated with the "master** 25 comprising: 

event pattern; f) displaying a date-delimited subset of the computer- 

4) Insert the non-recurring database row for the event; and implemented personal calendar. 

5) Create and possibly insert the new event object 8. Tbe computer-implemented method of claim 1, further 
instance into the internal cache. comprising: 

A similar but opposite set of actions is performed when 30 0 accepting user input describing at least one personal 

converting a non-recurring event to a recurring event. event; and 

From the above description, it will be apparent that the g) integrating the personal event with the selected event in 

invention disclosed herein provides a novel and advanta- the computer-implemented personal calendar, 

geous system and method of multi-layered online calendar- 9. The computer-implemented method of claim 8, further 

ing and purchasing. The foregoing discussion discloses and 35 comprising: 

describes merely exemplary methods and embodiments of h) selectively publishing the personal event to a group 

the present invention. As will be understood by those calendar. 

familiar with the art, tbe invention may be embodied in other 10. The computer-implemented method of claim 9, fur- 
specific forms without departing from the spirit or essential ther comprising: 

characteristics thereof. Accordingly, the disclosure of the 40 i) accepting input specifying a group of users to have 

present invention is intended to be illustrative, but not access to the group calendar; 

limiting, of the scope of the invention, which is set forth in j) accepting input from a second user requesting infor- 

the following claims. mation from the group calendar, and 

What is claimed is: k) responsive to the second user being specified in the 

1. A computer-implemented method for multi-layered « group, selectively transmitting the information from the 

online calendaring, comprising: group calendar to the second user. 

a) accepting user input specifying at least one of a 11. The computer-implemented method of claim 9, further 
plurality of categories; comprising: 

wherein at least one category of the plurality of cat- i) accepting input specifying a group of users to have 

egories corresponds to a unique visual characteristic; 50 access to the group calendar, 

b) retrieving a plurality of events associated with the j) designating a permitted level of access for each user in 
. i; specified category, each having a date; _ the group;. 

c) selectively displaying a date-delimited subset of tie k) accepting input from a second user requesting access to 
retrieved events associated with the specified category; 55 the group calendar; 

d) accepting user input selecting at least one of the 1) responsive to the second user being specified in the 
displayed events; group, and to the requested access corresponding to the 

e) adding the selected event to a computer-implemented permitled level of access for the second user, allowing 
personal calendar; the requested access to the group calendar; and 

f) repeating steps a) through e); and 60 m) responsive to the second user not being specified in the 

g) displaying the computer-implemented personal calen- group, or to the requested access not corresponding to 
dar by overlaying information from the selected events the, permitted level of access for the second user, 
from the specified categories on a common display, tbe denying tbe requested access to the group calendar, 
information for at least one event in a category being 12- The computer-implemented method of claim 1, fur- 
displayed uses the unique visual characteristic cone- 65 ther comprising: 

sponding to the category if the category corresponds to f) accepting user input describing at least one personal 

a unique visual characteristic. event; and 
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g) displaying the oomputer-implemented personal calen- 25. The computer-implemented method of claim 1, fur- 

dar by overlaying the personal event onto the at least ther comprising: 

one selected event from the at least one specified displaying a list of categories identified as newly avail- 

category on a common display. ^ t 

13. Hie computer-implemented method of claim 1, fur- 5 26. The computer-implemented method of claim U fur- 
ther comprising: mer 0,^^. 

£) accepting user input modifying the selected event; displaying a list of events identified as newly available, 
g) recording the modified selected event in the computer- 27. The computer-implemented method of claim 1, fur- 
implemented personal calendar. mer comprising- 

14. Tne computer-implemented method of claim 1, 10 ^ ^ ^ m section with the selected 
wnerein a) comprises. cvcnt ^ at a ptcdci£Tm j ssed ^ relativc to ^ dalc of ^ 

a.1) transmitting a page to a screen viewable by the user, event 

the page containing a plurality of links, each link 28. The* computer-implemented method of claim 1, fur- 
associated with a category; and ther comprising: 

a. 2) detecting user activation of a link specifying one of * f) outputting ao audio a i ert in connection with the selected 

the categories; event, at a predetermined time relative to the date of the 

and wherein c) comprises: event 

c.l) transmitting a page to a screen viewable by the user, 2 9. The" computer-implemented method of claim 1, fur- 

the page containing a plurality of links, each link ther comprising- 

associated with a retrieved event belonging to a date- 20 0 a m ^^on with the 

delimited subset of the retneved events associated with elected event, at a predetermined time relative to the 

. •^ s P ec ^ ed ^ory, of ^ evenL 

and wnerein d) comprises: 30. A computer-implemented system for multi-layered 

a 2 > detecting user activation of a link specifying one of onlinc calendaring, comprising: 
the d isd laved events 

« . • \ 4 . . , f . . a user input device for accepting user input specifying at 

15. The computer-implemented method of claim 14, , . c i i-, * . • * 

„. . . r \ r t v , . ^ . . ' least one of a plurality of categories, and for accepting 

wherein each of steps a.l) and c.l) comprise transmittinc a 4 \ ' , f , r 

. _*_T. r * i j . . 6 7 user input selecting at least one of a plurality of 

page via a hypertext transfer protocol, and wherein each displayed events; 

transmitted page comprises a hypertext-encoded document. , 

16. The computer-implemented method of claim 1, 30 wherein at least one category of the plurality of categories 
wherein each of steps a) and c) are performed by transmit- corresponds to a unique visual characteristic; 

ting a file across a computer network. an event retrieval module, coupled to the user input 

17. The computer-implemented method of claim 1, device, for retrieving a plurality of events associated 
wherein b) comprises retrieving a plurality of events from an wWl me specified category, each event having a date; 
externally-hosted database. 35 a display module, coupled to the event retrieval module, 

18. The computer-implemented method of claim 1, fur- for selectively displaying a date -delimited subset of the 
ther comprising: retrieved events associated with the specified category; 

f) accepting user input specifying that the computer- wherein the information for at least one event in the 
implemented personal calendar is to be shared with a ^ specified category is displayed using the unique visual 
second user; and characteristic corresponding to the specified category if 

g) accepting input from the second user requesting the the specified category corresponds to a unique visual 
computer-implemented personal calendar; and characteristic; and 

h) selectively transmitting at least a portion of the a personal calendar storage device, coupled to the user 
computer-implemented personal calendar to the second 45 input device, for adding a selected event to a computer- 
user, implemented personal calendar. 

19. The computer-implemented method of claim 1, 31. The computer-implemented system of claim 30, 
wherein c) comprises selectively displaying a subset of the wherein the display module displays the computer- 
retrieved events associated with a user-specified date. implemented personal calendar by overlaying information 

20. The computer-implemented method of claim 1, 50 from at least two selected events from at least one specified 
wherein c) comprises selectively displaying a subset of the category on a common display. 

retrieved events associated with a user-specified month. 32. The computer-implemented system of claim 30, fur- 

. -21. The computer-implemented method of claim 1, ther comprising a poirchasing .module, coupled to the user 

wherein c) comprises selectively displaying a subset of the input device, for processing a user-specified purchase asso- 

retrieved events associated with a user-specified week. 55 ciated with the selected event. 

22. The computer-implemented method of claim 1, 33. The computer-implemented system of claim 30, 
wherein b) further comprises: wherein: 

b. l) retrieving at least one event from a personal calendar the user input device further accepts user input describing 
of a second user. at least one personal event; and 

23. The computer-implemented method of claim 1, 60 the display module displays the computer-implemented 
wherein b) further comprises: personal calendar by overlaying the personal event onto 

b.l) retrieving at least one event from a group calendar. the at least one selected event from the at least one 

24. The computer-implemented method of claim 1, specified category on a common display. 

wherein each of at least of a subset of the events has a 34. The computer-implemented system of claim 30, fur- 
location, and wherein b) comprises retrieving a plurality of 65 Iher comprising: 

events associated with the specified category and having a an alert device, coupled to the personal calendar storage 

location corresponding to a specified location. device, for displaying an alert in connection with the 
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selected event, at a predetermined time relative to the 
date of the event. 

35. The computer-implemented system of claim 30, fur- 
ther comprising: 

an alert device, coupled to the personal calendar storage 5 
device, for outputting an audio alert in connection with 
the selected event, at a predetermined time relative to 
the date of the event. 

36. The computer-implemented system of claim 30, fur- 
ther comprising: 10 

a group calendar publishing module, coupled to the per- 
sonal calendar storage device, for selectively publish- 
ing the personal event to a group calendar storage 
device. 

37. The computer-implemented system of claim 36, 15 
wherein: 

the user input device accepts input specifying a group of 
users to have access to the group calendar, and 

the group calendar storage device accepts input from a 
second user requesting information from the group 20 
calendar, and, responsive to the second user being 
specified in the group, selectively transmits the infor- 
mation from the group calendar to the second user. 

38. A computer-implemented system for multi-layered 
online calendaring, comprising: 25 

an events database, containing a plurality of events, each 
event associated with at least one category, each event 
having a date; 

a personal category database, containing personal calen- 
dar information for a user; 30 

wherein at least one category corresponding to the events 
database or the personal category database corresponds 
to a unique visual characteristic; 

an application server, coupled to the events database and 35 
to the personal calendar database, for retrieving a 
plurality of events from the events database, the plu- 
rality of events being associated with a specified 
'-. . .category, and for retrieving personal calendar informa- 
tion from the personal calendar database; and ^ 

a display device, coupled to the application server, for 
selectively displaying a date-delimited subset of the 
retrieved events associated with the specified category, 
the information for at least one event in the specified 
category is displayed using the unique visual charac- 45 
teristic corresponding to the specified category if the 
specified category corresponds to a unique visual char- 
acteristic. 

39. The computer-implemented system of claim 38, fur- 
ther comprising a user input device coupled to the applica- ^ 
tion service, wherein: 

the application server, responsive to the user specifying an 
• event «fron> the dispkyed dale^elimiting subset, adds 
the specified event to the personal calendar information 
for the user. 55 

40. The computer-implemented system of claim 39, 
wherein the display device selectively displays a computer- 
implemented personal calendar by overlaying information 
from user-specified events. 

41. A computer-implemented system for multi-layered go 
online calendaring, comprising: 

user input means, for accepting user input specifying at 
least one of a plurality of categories, and for accepting 
user input selecting at least one of a plurality of 
displayed events; $5 

wherein at least one category of the plurality of categories 
corresponds to a unique visual characteristic; 
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event retrieval means, coupled to the user input means, for 
retrieving a plurality of events associated with the 
specified category, each event having a date; 

display means, coupled to the event retrieval means, for 
selectively displaying a date-delimited subset of the 
retrieved events associated with the specified category, 
the information for at least one event in the specified 
category is displayed using the unique visual charac- 
teristic corresponding to the specified category if the 
specified category corresponds to a unique visual char- 
acteristic; and 

personal calendar storage means, coupled to the user input 
means, for adding a selected event to a computer- 
implemented personal calendar. 

42. The computer-implemented system of claim 41, 
wherein the display means displays the computer- 
implemented personal calendar by overlaying information 
from at least two selected events from at least one specified 
category on a common display. 

43. The computer-implemented system of claim 41, fur- 
ther comprising purchasing means, coupled to the user input 
means, for processing a user-specified purchase associated 
with the selected event. 

44. The computer-implemented system of claim 41, 
wherein: 

the user input means further accepts user input describing 
at least one personal event; and 

the display means displays the computer-implemented 
personal calendar by overlaying the personal event onto 
the at least one selected event from the at least one 
specified category on a common display. 

45. The computer-implemented system of claim 41, fur- 
ther comprising: 

alert means, coupled to the personal calendar storage 
means, for displaying an alert in connection with the 
selected event, at a predetermined time relative to the 
date of the event. 

46. The computer-implemented system of claim 41, fur- 
ther comprising: 

alert means, coupled to the personal calendar storage 
means, for outputting an audio alert in connection with 
the selected event, at a predetermined time relative to 
the date of the event. 

47. The computer-implemented system of claim 41, fur- 
ther comprising: 

group calendar publishing means, coupled to the personal 
calendar storage means, for selectively publishing the 
personal event to a group calendar storage means. 

48. The computer-implemented system of claim 47, 
wherein: 

the user input means accepts. mr>ut. specifying a group of 
users to have access to the group calendar, and 

the group calendar storage means accepts input from a 
second user requesting information from the group 
calendar, and, responsive to the second user being 
specified in the group, selectively transmits the infor- 
mation from the group calendar to the second user. 

49. A computer program product comprising a computer- 
usable medium having computer-readable code embodied 
therein for multi-layered online calendaring, comprising: 

computer-readable program code devices configured to 
cause a computer to accept user input specifying at 
least one of a plurality of categories, and to accept user 
input selecting at least one of a plurality of displayed 
events; 
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wherein at least one category of the plurality of categories 
corresponds to a unique visual characteristic; 

computer-readable program code devices configured to 
cause a computer to retrieve a plurality of events 
associated with the specified category, each event hav- 
ing a date; 

computer-readable program code devices configured to 
cause a computer to selectively display a date-delimited 
subset of the retrieved events associated with the speci- 
fied category, the information for at least one event in 
the specified category is displayed using the unique 
visual characteristic corresponding to the specified cat- 
egory if the specified category corresponds to a unique 
visual characteristic, and 

computer-readable program code devices configured to 
cause a computer to add a selected event to a computer- 
implemented personal calendar. 

50. The computer program product of claim 49, wherein 
the computer-readable program code devices configured to 
cause a computer to selectively display are configured to 
cause a computer to display the computer-implemented 
personal calendar by overlaying information from at least 
two selected events from at least one specified category on 
a common display 

51. The computer program product of claim 49, further 
comprising computer-readable program code devices con- 
figured to cause a computer to process a user-specified 
purchase associated with the selected event 

52. The computer program product of claim 49, wherein: 
the computer-readable program code devices configured 

to cause a computer to accept user input are configured 
to cause a computer to accept user input describing at 
least one personal event; and 
the computer-readable program code devices configured 
to cause a computer to selectively display are config- 
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ured to cause computer to display the computer- 
implemented personal calendar by overlaying the per- 
sonal event onto the at least one selected event from the 
at least one specified category on a common display 

53. The computer program product of claim 49, further 
comprising: 

computer-readable program code devices configured to 
cause a computer to display an alert in connection with 
the selected event, at a predetermined time relative to 
the date of the event. 

54. The computer program product of claim 49, further 
comprising: 

computer-readable program code devices configured to 
cause a computer to output an audio alert in connection 
with the selected event, at a predetermined time relative 
to the date of the event 

55. The computer program product of claim 49, further 
comprising: 

computer-readable program code devices configured to 
cause a computer to selectively publish the personal 
event to a group calendar storage device. 

56. The computer program product of claim 55, wherein: 
the computer-readable program code devices configured 

to cause a computer to accept user input are configured 
to cause a computer to accept input specifying a group 
of users to have access to the group calendar; and 
the group calendar storage device accepts input from a 
second user requesting information from the group 
calendar, and, responsive to the second user being 
specified in the group, selectively transmits the infor- 
mation from the group calendar to the second user. 
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USPTO TO PROVIDE ELECTRONIC ACCESS TO CITED U.S. 
PATENT REFERENCES WITH OFFICE ACTIONS AND CEASE 

SUPPLYING PAPER COPIES 



In support of its 21 st Century Strategic Plan goal of increased patent e-Government, beginning in 
June 2004, the United States Patent and Trademark Office (Office or USPTO) will begin the phase- 
in of its E-Patent Reference program and hence will: (1) provide downloading capability of the 
U.S. patents and U.S. patent application publications cited in Office actions via the E-Patent 
Reference feature of the Office's Patent Application Information Retrieval (PAIR) system; and (2) 
cease mailing paper copies of U.S. patents and U.S. patent application publications with 
Office actions (in applications and during reexamination proceedings) except for citations made 
during the international stage of an international application under the Patent Cooperation Treaty 
(PCT). In order to use the new E-Patent Reference feature applicants must: (1) obtain a digital 
certificate and software from the Office; (2) obtain a customer number from the Office; and (3) 
properly associate patent applications with the customer number. Alternatively, copies of all U.S. 
patents and patent application publications can be accessed without a digital certificate from the 
USPTO web site, from the USPTO Office of Public Records, and from commercial sources. The 
Office will continue the practice of supplying paper copies of foreign patent documents and non- 
patent literature with Office actions. Paper copies of cited references will continue to be provided 
by the USPTO for international applications during the international stage. 

Schedule 



June 2004 TCs 1 600, 1 700, 2800 and 2900 

July 2004 TCs 3600 and 3700 

August 2004 TCs 2 1 00 and 2600 

All U.S. patents and U.S. patent application publications are available on the USPTO web site. 
However, a simple system for downloading the cited U.S. patents and patent application 
publications has been established for applicants, called the E-Patent Reference system. As E-Patent 
Reference and Private PAIR require participating applicants to have a customer number, retrieval 
software and a digital certificate, all applicants are strongly encouraged to contact the Patent 
Electronic Business Center to acquire these items. To be ready to use this system by June 1, 2004, 
contact the Patent EBC as soon as possible by phone at 866-217-9197 (toll-free), 703-305-3028 or 
703-308-6845 or electronically via the Internet at ebc@.uspto.gov. 



Other Options 

The E-Patent Reference function requires the applicant to use the secure Private PAIR system, 
which establishes confidential communications with the applicant. Applicants using this facility 
must receive a digital certificate, as described above. Other options for obtaining patents which do 
not require the digital certificate include the USPTO' s free Patents on the Web program 
(http://www.uspto.gov/patft/index.html). The USPTO's Office of Public Records also supplies 
copies of patents for a fee fhtto://ebizl.uspto.gov/oems25p/index.htmn . Commercial sources also 
provide U.S. patents and patent application publications. 

For complete instructions see the Official Gazette Notice, USPTO TO PROVIDE ELECTRONIC ACCESS TO CITED 
U.S. PATENT REFERENCES WITH OFFICE ACTIONS AND CEASE SUPPLYING PAPER COPIES, on the 
USPTO web site. 



NOTICE OF OFFICE PLAN TO CEASE SUPPLYING COPIES OF CITED U.S. PATENT 
REFERENCES WITH OFFICE ACTIONS, AND PILOT TO EVALUATE THE 
ALTERNATIVE OF PROVIDING ELECTRONIC ACCESS TO SUCH U.S. PATENT 

REFERENCES 



Summary 

The United States Patent and Trademark Office (Office or USPTO) plans in the near future to: 

(1) cease mailing copies of U.S. patents and U.S. patent application publications (US patent 
references) with Office actions except for citations made during the international stage of an 
international application under the Patent Cooperation Treaty and those made during 
reexamination proceedings; and (2) provide electronic access to, with convenient downloading 
capability of, the US patent references cited in an Office action via the Office's private Patent 
Application Information Retrieval (PAIR) system which has a new feature called "E-Patent 
Reference." Before ceasing to provide copies of U.S. patent references with Office actions, the 
Office shall test the feasibility of the E-Patent Reference feature by conducting a two-month pilot 
project starting with Office actions mailed after December 1, 2003. The Office shall evaluate the 
pilot project and publish the results in a notice which will be posted on the Office's web site 
fwww.USPTO.gov) and in the Patent Official Gazette (O.G.). In order to use the new E-Patent 
Reference feature during the pilot period, or when the Office ceases to send copies of U.S. patent 
references with Office actions, the applicant must: (1) obtain a digital certificate from the Office; 

(2) obtain a customer number from the Office, and (3) properly associate applications with the 
customer number. The pilot project does not involve or affect the current Office practice of 
supplying paper copies of foreign patent documents and non-patent literature with Office actions. 
Paper copies of references will continue to be provided by the USPTO for searches and written 
opinions prepared by the USPTO for international applications during the international stage and 
for reexamination proceedings. 

Description of Pilot Project to Provide Electronic Access to Cited U.S. Patent 
References 

On December 1, 2003, the Office will make available a new feature, E-Patent Reference, in the 
Office's private PAIR system, to allow more convenient downloading of U.S. patents and U.S. 
patent application publications. The new feature will allow an authorized user of private PAIR 
to download some or all of the U.S. patents and U.S. patent application publications cited by an 
examiner on form PTO-892 in Office actions, as well as U.S. patents and U.S. patent application 
publications submitted by applicants on form PTO/SB08 (1449) as part of an IDS. The retrieval 
of some or all of the documents may be performed in one downloading step with the documents 
encoded as Adobe Portable Document format ( pdf) files, which is an improvement over the 
current page-by-page retrieval capability from other USPTO systems. 



Steps to Use the New E -Patent Reference Feature During the Pilot Project and 
Thereafter 

Access to private PAIR is required to utilize E-Patent Reference. If you don* t already have 
access to private PAIR, the Office urges practitioners, and applicants not represented by a 
practitioner, to take advantage of the transition period to obtain a no-cost USPTO Public Key 
Infrastructure (PKI) digital certificate, obtain a USPTO customer number, associate all of their 
pending and new application filings with their customer number, install no-cost software 
(supplied by the Office) required to access private PAIR and E-Patent Reference feature, and 
make appropriate arrangements for Internet access. The full instructions for obtaining a PKI 
digital certificate are available at the Office's Electronic Business Center (EBC) web page at: 
<ittp://www.uspto.gov/ebc/downloads.html> . Note that a notarized signature will be required to 
obtain a digital certificate. 

To get a Customer Number, download and complete the Customer Number Request form, PTO- 
SB125, at: httD://www.uspto.gov/web/forms/sb012S.pdf . The completed form can then be 
transmitted by facsimile to the Electronic Business Center at (703) 308-2840, or mailed to the 
address on the form. If you are a registered attorney or patent agent, then your registration 
number must be associated with your customer number. This is accomplished by adding your 
registration number to the Customer Number Request form. A description of associating a 
customer number with an application is described at the EBC web page at: 
http://www.uspto.gov/ebc/regi8tration pair.html . 

The E-Patent Reference feature will be accessed using a new button on the private PAIR screen. 
Ordinarily all of the cited U.S. patent and U.S. patent application publication references will be 
available over the Internet using the Office's new E-Patent Reference feature. The size of the 
references to be downloaded will be displayed by E-Patent Reference so the download time can 
be estimated. Applicants and registered practitioners can select to download all of the references 
or any combination of cited references. Selected references will be downloaded as complete 
documents as Adobe Portable Document Format (.pdf) files. For a limited period of time, the 
USPTO will include a copy of this notice with Office actions to encourage applicants to use this 
new feature and, if needed, to take the steps outlined above in order to be able to utilize this new 
feature during the pilot and thereafter. 

During the two-month pilot, the Office will evaluate the stability and capacity of the E-Patent 
Reference feature to reliably provide electronic access to cited U.S. patent and U.S. patent 
application publication references. While copies of U.S. patent and U.S. patent application 
publication references cited by examiners will continue to be mailed with Office actions during 
the pilot project, applicants are encouraged to use the private PAIR and the E-Patent Reference 
feature to electronically access and download cited U.S. patent and U.S. patent application 
publication references so the Office will be able to objectively evaluate its performance. The 
public is encouraged to submit comments to the Office on the usability and performance of the 
E-Patent Reference feature during the pilot. Further, during the pilot period registered 
practitioners, and applicants not represented by a practitioner, are encouraged to experiment with 
the feature, develop a proficiency in using the feature, and establish new internal processes for 
using the new access to the cited U.S. patents and U.S. patent application publications to prepare 
for the anticipated cessation of the current Office practice of supplying copies of such cited 
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references. The Office plans to continue to provide access to the E-Patent Reference feature 
during its evaluation of the pilot 



Comments 

Comments concerning the E-Patent Reference feature should be in writing and directed to the 
Electronic Business Center (EBC) at the USPTO by electronic mail at e^ference^ujBtg^gpv or 
by facsimile to (703) 308-2840. Comments will be posted and made available for public 
inspection. To ensure that comments are considered in the evaluation of the pilot project, 
comments should be submitted in writing by January 15, 2004. 

Comments with respect to specific applications should be sent to the Technology Centers* 
customer service centers. Comments concerning digital certificates, customer numbers, and 
associating customer numbers with applications should be sent to the Electronic Business Center 
(EBC) at the USPTO by facsimile at (703) 308-2840 or by e-mail at EBC@uspto.gov. 

Implementation after Pilot 

After the pilot, its evaluation, and publication of a subsequent notice as indicated above, the 
Office expects to implement its plan to cease mailing paper copies of U.S. patent references cited 
during examination of non provisional applications on or after February 2, 2004; although copies 
of cited foreign patent documents, as well as non-patent literature, will still be mailed to the 
applicant until such time as substantially all applications have been scanned into IFW. 

For Further Information Contact 

Technical information on the operation of the IFW system can be found on the USPTO website 
at http://www.uspto.gov/web/patents/ifw/index.html. Comments concerning the E-Patent 
Reference feature and questions concerning the operation of the PAIR system should be directed 
to the EBC at the USPTO at (866) 217-9197. The EBC may also be contacted by facsimile at 
(703) 308-2840 or by e-mail at EBC@uspto.gov. 
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